I think the easiest solution is to allocate a second fixed
notification vector for vmcs02. If the L2 vector arrives while vmcs01
is active, we suffer an unnecessary VM-exit, but at least if the L1
vector arrives while vmcs02 is active, we will know to synthesize a
VM-exit from L2 to L1 (if vmcs01's PI descriptor indicates that there
is a virtual interrupt to be delivered).
On Wed, Apr 19, 2017 at 2:10 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
>
> On 18/04/2017 21:56, Jim Mattson wrote:
>> In commit 705699a139948 ("KVM: nVMX: Enable nested posted interrupt
>> processing"), nested posted interrupts are implemented such that
>> vmcs02 uses the same notification vector as vmcs01. I don't understand
>> how this can work.
>>
>> Suppose that VCPU0 is in L2, with posted interrupts enabled (for
>> simplicity, let's say that the notification vector in vmcs12 is 0xf1,
>> the same as in vmcs01 and vmcs02). Furthermore, suppose that L2 is
>> halted, with the pin-based vm-execution control for
>> "external-interrupt exiting" enabled.
>>
>> Now, suppose that VCPU1 is in L1, and it wants to send an IPI (say
>> 0xc7) to VCPU0 (which it doesn't know is in L2...and shouldn't have to
>> know). vmx_deliver_posted_interrupt will set the PIR and ON bits in
>> VCPU0's vmcs01 posted interrupt descriptor and then it will send a
>> 0xf1 IPI to the pCPU running VCPU0.
>>
>> Hardware will recognize that 0xf1 is the notification vector for
>> vmcs02, and it will process vmcs02's posted interrupt descriptor.
>> Finding nothing of interest there, it will return to the halt state,
>> without a VM-exit.
>>
>> Something should trigger L0 to synthesize an external interrupt
>> VM-exit from L2 to L1 for vector 0xc7. However, I don't see how this
>> happens.
>>
>> What am I missing?
>
> Nothing, I think you're right.
>
> Paolo
