Re: [Xen-devel] [PATCH] schedule: mask out XEN_RUNSTATE_UPDATE from state entry time

[Jan Beulich <JBeulich@xxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel