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

[Tim Deegan <tim@xxxxxxx>]

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.

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?)

Cheers,

Tim.

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