Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, March 05, 2015 8:03 PM
> To: Jan Beulich
> Cc: Wu, Feng; Zhang, Yang Z; Tian, Kevin; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
> 
> Hi,
> 
> At 08:52 +0000 on 05 Mar (1425541947), Jan Beulich wrote:
> > >>> On 05.03.15 at 09:29, <feng.wu@xxxxxxxxx> wrote:
> > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > >> Sent: Thursday, March 05, 2015 3:13 PM
> > >> And if it can know, why couldn't the handler for
> > >> posted_intr_vector not know either (i.e. after introducing a specific
> > >> handler for it in place of the currently used event_check_interrupt)?
> > >
> > > Come back to the above scenario, vCPU1 is running on pCPU0 while vCPU0
> > > is blocked, if we still use posted_intr_vector for the blocked vCPU0. If
> > > vCPU1
> > > is running in non-root mode and external interrupts happen for it, the
> > > notification
> > > event will be handled by CPU hardware (in non-root mode) automatically,
> > > then we cannot get any control in the handler for posted_intr_vector.
> >
> > And how would this be different with your separate new vector? I
> > feel I'm missing something, but I'm afraid I have to rely on you to
> > point out what it is. Just again - please explain what it is you need
> > two global vectors for that can't be done with one.
> 
> I think the relevant detail is that the posted_intr_vector is consumed
> by the CPU's posted-interrupt logic and doesn't cause an exit to Xen.
> 

Exactly!

> But I don't understand why we would need a new global vector for
> RUNSTATE_blocked rather than suppressing the posted interrupts as you
> suggest for RUNSTATE_runnable.  (Or conversely why not use the new
> global vector for RUNSTATE_runnable too?)

If we suppress the posted-interrupts when vCPU is blocked, it cannot
be unblocked by the external interrupts, this is not correct.

Thanks,
Feng

> 
> Cheers,
> 
> Tim.

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