Message-ID: <8b2ff3dc317db18c8128381d5d62057a90f68265.camel@redhat.com>
Date:   Tue, 19 Apr 2022 09:44:48 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Gaoning Pan <pgn@....edu.cn>,
        Yongkang Jia <kangel@....edu.cn>
Subject: Re: [PATCH 2/4] KVM: nVMX: Defer APICv updates while L2 is active
 until L1 is active

On Mon, 2022-04-18 at 15:35 +0000, Sean Christopherson wrote:
> On Mon, Apr 18, 2022, Maxim Levitsky wrote:
> > On Sat, 2022-04-16 at 03:42 +0000, Sean Christopherson wrote:
> > When L2 uses APICv/AVIC, we just safely passthrough its usage to the real hardware.
> > 
> > If we were to to need to inhibit it, we would have to emulate APICv/AVIC so that L1 would
> > still think that it can use it - thankfully there is no need for that.
> 
> What if L1 passes through IRQs and all MSRs to L2? 

KVM absolutely should inhibit L1 AVIC/APICv in this case if L2 triggers AUTOEOI inhibit via msr write via non
intercepted msr, and I don't see why it won't work.

It should not affect L2's APICv/AVIC though, only L1 can decide that it wants to inhibit it,
and it has all the means to do so without any help from L0.


In regard to APICv, neither vmcs02 nor vmcs01 should need to be touched on a vCPU
that does this though:
 
 
- vmcs02 can't have APICv enabled, because passthrough of interrupts thankfully
  conflicts with APICv (virtual interrupt delivery depends on intercepting interrupts)
  and even if that was false, it would have contained L2's APICv settings which should
  continue to work as usual.
 
- vmcs01 isn't active on this vCPU, so no need to touch it. vmcs01 of other vCPUs
  which don't run nested, does need to be updated to have APICv inhibited, 
  which should work just fine unless there are bugs in KVM's APICv.
 
 
- Posted interrupts that target L1 will be delivered as normal interrupts and cause KVM to 
  inject them to L2 (because of no interception)
 
- Posted interrupts that target L2 can't even happen because APICv can't be enabled in L1

 
In regard to SVM, in theory you can have interrupt intercept disabled and yet have AVIC enabled
in both L0 and L1, but it should work just fine as well:
 
In this case, while running nested:
 
L2 if it has direct access to L1's AVIC, will be able to write there but all writes will
be normal MMIO writes and work as usual but not accelerated.
 
Interrupts that target L1 will not go through AVIC, but be delivered via normal IPIs,
because L1's avic is inhibited on this vCPU locally, and then KVM will inject them to L2.
 
Interrupts that target L2 will go through nested AVIC and land there just fine.
 
AVIC inhibition/uninhibition in this case has 0 effect on this vCPU, as L1 AVIC is already
inhibited locally on this vCPU, and my code will correctly do nothing in this case.

Yes in theory, when L1 doesn't use AVIC for L2, and passes through all interrupts to L2,
I could have setup vmcb02 to use L0's AVIC and let interrupts that target L1 go to L2
via AVIC, but it is just not worth the complexity this adds, and it might not even
work correctly in some cases, since L1 still has its own APIC, even if it doesn't
really receive interrupts while L2 is running.

 
IMHO it all adds up.
 
Best regards,
	Maxim Levitsky



>   L1 isn't expecting a VM-Exit, so
> KVM can't safely punt to L1 even if conceptually we think that it's L1's problem.
> 
> It's a contrived scenario, but technically possible.
> 

Powered by blists - more mailing lists