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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.03.15 at 14:30, <feng.wu@xxxxxxxxx> wrote:
> - Introduce a new global vector which is used to wake up the HLT'ed vCPU.
> Currently, there is a global vector 'posted_intr_vector', which is used as 
> the
> global notification vector for all vCPUs in the system. This vector is 
> stored in
> VMCS and CPU considers it as a special vector, uses it to notify the related
> pCPU when an interrupt is recorded in the posted-interrupt descriptor.
> 
> After having VT-d PI, VT-d engine can issue notification event when the
> assigned devices issue interrupts. We need add a new global vector to
> wakeup the HLT'ed vCPU, please refer to the following scenario for the
> usage of this new global vector:
> 
> 1. vCPU0 is running on pCPU0
> 2. vCPU0 is HLT'ed and vCPU1 is currently running on pCPU0
> 3. An external interrupt from an assigned device occurs for vCPU0, if we
> still use 'posted_intr_vector' as the notification vector for vCPU0, the
> notification event for vCPU0 (the event will go to pCPU1) will be consumed
> by vCPU1 incorrectly. The worst case is that vCPU0 will never be woken up
> again since the wakeup event for it is always consumed by other vCPUs
> incorrectly. So we need introduce another global vector, naming 
> 'pi_wakeup_vector'
> to wake up the HTL'ed vCPU.

I'm afraid you describe a particular scenario here, but I don't see
how this is related to the introduction of another global vector:
Either the current (global) vector is sufficient, or another global
vector also can't solve your problem. I'm sure I'm missing something
here, so please be explicit.

> - Update posted-interrupt descriptor during vCPU scheduling
> The basic idea here is:
> 1. When vCPU's state is RUNSTATE_running,
>         - Set 'NV' to 'posted_intr_vector'.
>         - Clear 'SN' to accept posted-interrupts.
>         - Set 'NDST' to the pCPU on which the vCPU will be running.
>[...]

This is pretty hard to read without knowing what the abbreviations
actually stand for, and suggesting to hunt for them in the spec isn't
very reader friendly either. Please explain these fields, at the very
least by way of comments on the structure fields presented earlier.

> On Xen side, what is your opinion about support lowest-priority interrupts
> for VT-d PI?

I certainly think (as with every other virtualized piece of hardware)
that hardware behavior should be emulated as closely as possible.
I.e. yes, we should have it eventually. As to the two stage approach
mentioned for KVM - I've grown reservations against Intel people
making promises towards future implementation of something, i.e.
I'm kind of hesitant to agree to such an implementation model. Yet
you're to contribute the patches, and I'm surely not planning to veto
a stage-1-only implementation as it would be an improvement anyway.

Jan


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