On 18.07.2019 16:12, Andrii Anisov wrote: > On 18.07.19 14:10, Jan Beulich wrote: >> A concrete scenario where update_runstate_area() and vcpu_runstate_change() >> can actually race would be very worthwhile to point out here. In particular >> on Arm I'm not (yet?) seeing how this could happen. > > The scenario is quite trivial: some vcpu uptdating its runstate values > (e.g. context switching) while those values are being read by a guest using > other vcpu.
Well, that's (afaia) not an intended usage scenario. That's specifically what the XEN_RUNSTATE_UPDATE flag was introduced for: This way guests can notice that they shouldn't use the values, as they're likely inconsistent. They'd pause for a brief moment and make another attempt; see Linux'es xen_get_runstate_snapshot_cpu_delta(). But neither from the code change nor from the description I would have implied that it's a guest side problem you're trying to address. So far I was assuming you had found a race in Xen itself. >> Considering the value of XEN_RUNSTATE_UPDATE it must be a rather rare race >> anyway, I would guess. > > I'm not sure how do you link the value of XEN_RUNSTATE_UPDATE and the issue > occurrence rate. Could you please provide more details about the idea? The value is huge, hence it being wrongly part of a calculation ought to be easily noticeable _if_ it occurred often enough. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
