Re: [Xen-devel] vcpu_block() and do_poll() question

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.04.19 at 15:35, <julien.grall@xxxxxxx> wrote:
> On 30/04/2019 14:33, Jan Beulich wrote:
>>>>> On 30.04.19 at 15:16, <julien.grall@xxxxxxx> wrote:
>>> On 30/04/2019 12:48, Jan Beulich wrote:
>>>>>>> On 30.04.19 at 12:44, <jgross@xxxxxxxx> wrote:
>>>>> Then we could drop this #ifndef section.
>>>>
>>>> Not sure about this - I'm actually unconvinced the latter part of
>>>> what's inside the #ifdef isn't actually needed on x86 as well. Just
>>>> consider the case of vcpu_unblock() making it to the vcpu_wake()
>>>> invocation on another CPU while we're between any two of the
>>>> three writes here. (I know I've been feeling uneasy about this
>>>> before, but I guess I must have come to the conclusion that it's
>>>> _probably_ okay.)
>>> That's not going to be covered by the check on non-x86 platform. Indeed,
>>> vcpu_wake() is not updating any of the fields. So, from my understanding, 
>>> the
>>> wake-up request will just be ignored.
>> 
>> Perhaps a misunderstanding (or I'm confused now): I mentioned
>> vcpu_wake() only to delimit how much of vcpu_unblock() needs
>> completing for the possible problem to surface that I'm suspecting.
> 
> I am not sure what problem you refer. Is it the wake-up request will get 
> ignored?

I've not noticed any risk of an ignored wakeup so far. What I did
notice is that if the initial part of vcpu_unblock() runs between any
two of the three stores in do_poll(), inconsistent state may result:
We may end up with VPF_blocked clear but ->poll_evtchn set to -1
and/or the respective poll_mask bit set. I've not done any analysis
to decide whether such inconsistent state could lead to actual issues.

With the (currently Arm-only) extra if() nothing like this can result
upon completion of do_poll().

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel