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

[Tim Deegan <tim@xxxxxxx>]

At 02:03 +0000 on 09 Mar (1425863009), Wu, Feng wrote:
> 
> 
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xxxxxxx]
> > Sent: Friday, March 06, 2015 5:44 PM
> > To: Wu, Feng
> > Cc: Jan Beulich; Zhang, Yang Z; Tian, Kevin; xen-devel@xxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] VT-d Posted-interrupt (PI) design for XEN
> > 
> > At 02:07 +0000 on 06 Mar (1425604054), Wu, Feng wrote:
> > > > From: Tim Deegan [mailto:tim@xxxxxxx]
> > > > 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.
> > 
> > OK, I don't understand at all now. :)  When the posted interrupt is
> > suppressed, what happens to the interrupt? 
> 
> When the posted interrupt is suppressed, VT-d engine will not issue
> notification events.
> 
> > If it's just dropped, then we can't use that for _any_ cases. 
> 
> We can suppress the posted-interrupt when vCPU is waiting in the runqueue
> (vCPU is in RUNSTATE_runnable state), it is not needed to send notification
> event when vCPU is in this state, since when interrupt happens, the interrupt
> information are not _dropped_, instead, they are stored in PIR, and this will
> be synced to vIRR before VM-Entry.

So you think you can use the same system for RUNSTATE_runnable as
RUNSTATE_blocked?  That seems like a good idea. 

I'll leave the details (e.g. single global vector + queue vs any other
way to wake the vcpu) to people who know the x86 irq code better than
I do. :)

Thanks for the clarification.

Tim.

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