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 6:15 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 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/6
> 4-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).

Sure, I will add the description later!

So things are a little clear now, could you please take some time to
review this design again and give more comments? Thanks a lot!!

Thanks,
Feng

> 
> Jan


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