[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yl7bzNi9HjbgIAQ5@google.com>
Date: Tue, 19 Apr 2022 15:57:00 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Maxim Levitsky <mlevitsk@...hat.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 Tue, Apr 19, 2022, Maxim Levitsky wrote:
> 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?
...
> - 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.
Ah, this was the critical piece I was forgetting. I'll tweak the changelog and
post a new version.
Thanks!
Powered by blists - more mailing lists