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?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
