On 30/04/2019 12:38, Jan Beulich wrote:
>>>> On 30.04.19 at 12:31, <julien.gr...@arm.com> wrote:
> 
>>
>> On 30/04/2019 11:27, Jan Beulich wrote:
>>>>>> On 30.04.19 at 11:13, <jgr...@suse.com> wrote:
>>>> In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
>>>> do_poll().
>>>>
>>>> It was introduced way before anyone would think about ARM by commit
>>>> ef4c6b079cc55e (I couldn't find any xen-devel mail related to that
>>>> commit), so I guess it is related to IA64?
>>>
>>> Quite certainly, yes (or PPC as an alternative, but I know nothing
>>> about their memory ordering model).
>>>
>>>> Question is: can we just drop it, or does ARM depend on it? And if ARM
>>>> really needs it, is it the memory barrier only? And why wouldn't a
>>>> similar barrier be needed in vcpu_block() then?
>>>
>>> It's not the memory barrier, but the subsequent checks. The barrier
>>> is there only to make sure the checks don't happen before the
>>> earlier writes. And as the comment says - it's the combination of
>>> the 3 writes that may get mis-ordered and hence mis-interpreted by
>>> other (reading) parties. vcpu_block(), otoh, sets the VPF_blocked
>>> bit only, so there's no potential ordering issue there.
>>
>> Are you suggesting the comment in vcpu_block is not correct?
> 
> No. But I'm not talking about the local_events_need_delivery()
> checks (which exist in both functions), but the ones inside the
> #ifdef in do_poll() (which have no equivalent in vcpu_block()).
> That's not to say that there may not need to be a barrier ahead
> of local_events_need_delivery() as well - I've simply not thought
> through that further case (yet).

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

Then we could drop this #ifndef section.


Juergen

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

Reply via email to