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

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

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, March 05, 2015 4:52 PM
> To: Wu, Feng
> Cc: Tian, Kevin; Zhang, Yang Z; xen-devel@xxxxxxxxxxxxx
> Subject: RE: VT-d Posted-interrupt (PI) design for XEN
> 
> >>> 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.

Stilling using the above scenario, if vCPU1 is running in non-root mode
and external interrupts happen for vCPU0 (who is HLT'ed).

If using 'posted_intr_vector' for vCPU0 and 'posted_intr_vector' is also
used for other vCPUs, including vCPU1. VT-d engine will issue notification
event using this global vector, and this SPECIAL vector will be handled
this way: (from Section 29.6 in the Intel SDM:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf)

1. The local APIC is acknowledged; this provides the processor core with an 
interrupt vector, called here the
physical vector.
2. If the physical vector equals the posted-interrupt notification vector, the 
logical processor continues to the next
step. Otherwise, a VM exit occurs as it would normally due to an external 
interrupt; the vector is saved in the
VM-exit interruption-information field.
3. The processor clears the outstanding-notification bit in the 
posted-interrupt descriptor. This is done atomically
so as to leave the remainder of the descriptor unmodified (e.g., with a locked 
AND operation).
4. The processor writes zero to the EOI register in the local APIC; this 
dismisses the interrupt with the postedinterrupt
notification vector from the local APIC.
5. The logical processor performs a logical-OR of PIR into VIRR and clears PIR. 
No other agent can read or write a
PIR bit (or group of bits) between the time it is read (to determine what to OR 
into VIRR) and when it is cleared.
6. The logical processor sets RVI to be the maximum of the old value of RVI and 
the highest index of all bits that
were set in PIR; if no bit was set in PIR, RVI is left unmodified.
7. The logical processor evaluates pending virtual interrupts as described in 
Section 29.2.1.

This is totally handled by CPU hardware, so we cannot get control in the 
handler for posted_intr_vector.

OTOH, if using 'pi_wakeup_vector' for vCPU0, VT-d engine will issue 
notification event using this new vector,
Since this new vector is not a SPECIAL one to CPU, it is just a normal vector. 
To cpu, it just receives an normal
external interrupt, then we can get control in the handler of this new vector. 
In this case, hypervisor can
do something in it, such as wakeup the HLT'ed vCPU.

Hope this can clarify your confusion.

Thanks,
Feng

> 
> Jan


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