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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.03.15 at 10:07, <feng.wu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Thursday, March 05, 2015 4:52 PM
>> 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-ar
>  
> chitectures-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, yes - it is this "vector-is-special-to-CPU" that makes a second
vector necessary. Please make sure this is being properly explained in
the description and/or code comments of the patches to come (of
course without need to quote the SDM, but a reference to the
respective section may be useful).

Jan


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