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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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:
>>> An alternative would be memory barriers between the writes on ARM,
>>> right? Or a strong ordered set_bit() variant (we had that discussion
>>> recently related to a barrier in ARM-specific __cpu_disable()).
> 
> I am not entirely a big fan of a strong-order variant. It will potentially 
> add 
> more memory barriers than necessary in this context.
> 
>> 
>> Yes.
> 
> What would be the advantage of 2-3 memory barriers over a memory barrier + 
> check?

Dunno - I've merely confirmed that this looks to be an alternative
correct solution.

>>> 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.

Jan



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