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