On Wed, 2016-01-20 at 01:35 -0700, Jan Beulich wrote: > > > > On 20.01.16 at 08:49, <feng...@intel.com> wrote: > > > > > We need to call arch_vcpu_block() before > > local_events_need_delivery(), > > since VT-d hardware can issue notification event when we are in > > arch_vcpu_block(), it that happens, 'ON' bit is set, then we will > > check > > it in local_events_need_delivery(). If we do arch_vcpu_block() in > > the > > else part, we cannot handle this. This is one reason I can recall, > > I am > > not sure whether there are other concerns since it has been really > > a long time. The current implementation is fully discussed with > > scheduler > > maintainers. > > Okay, this all makes sense. > Yes, I proposed / asked about that here: http://bugs.xenproject.org/xen/mid/%3c1445948204.2937.130.ca...@citrix.com%3E
As Feng says, the whole idea is doing one last check before actually blocking, to see whether we can avoid doing so, if an event has arrived in the meantime. It can be seen as an optimization (whether a really effective one, I can't tell). In fact, an event can well come just immediately after local_events_need_delivery() has returned false! We somehow do the same thing already in vcpu_block(), and consistency with that was what convinced me that we can live with Feng's code as it is in this patch. > It's just that I don't see how the ON > bit would get checked by local_events_need_delivery(). But that > may in turn be because, with the long turnaround, I've lost some > of the details of the rest of this series. > I think what Feng means is "if that happens [== that an event arrives], 'ON' bit is set, then we will check it [== whether an event has arrived] in local_events_need_delivery()." If *no* event has arrived, no need to do anything particular, we can just block. If an event *has* arrived in time for local_events_need_delivery() to see it, we avoid blocking. We do need to rollback what arch_vcpu_block() did, and that is done while leaving the hypervisor, as soon as we realize we haven't blocked. If we put the hook in 'else', we'd always go down the full blocking path, even if an event became pending while arranging for that, and we'll have to be woken again, as soon as the event is handled. How effective an optimization this is depends on how probable and frequent it is that we get interrupts during the execution of the hook, which, as said, it's not easy to either just tell or measure. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
