[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] vcpu_block() and do_poll() question
>>> On 30.04.19 at 12:31, <julien.grall@xxxxxxx> wrote: > > On 30/04/2019 11:27, Jan Beulich wrote: >>>>> On 30.04.19 at 11:13, <jgross@xxxxxxxx> 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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |