Re: [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2792 bytes --]

On Wed, 2016-01-20 at 01:35 -0700, Jan Beulich wrote:
> > > > On 20.01.16 at 08:49, <feng.wu@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.camel@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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel