Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 7 Aug 2023 11:04:48 -0700
In-Reply-To: <43c18a3d57305cf52a1c3643fa8f714ae3769551.camel@redhat.com>
Mime-Version: 1.0
References: <20230807062611.12596-1-ake@igel.co.jp> <43c18a3d57305cf52a1c3643fa8f714ae3769551.camel@redhat.com>
Message-ID: <ZNEyQM8CYSAcyt9F@google.com>
Subject: Re: [RFC PATCH] KVM: x86: inhibit APICv upon detecting direct APIC
 access from L2
From:   Sean Christopherson <seanjc@google.com>
To:     Maxim Levitsky <mlevitsk@redhat.com>
Cc:     Ake Koomsin <ake@igel.co.jp>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H . Peter Anvin" <hpa@zytor.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Aug 07, 2023, Maxim Levitsky wrote:
> =D0=A3 =D0=BF=D0=BD, 2023-08-07 =D1=83 15:26 +0900, Ake Koomsin =D0=BF=D0=
=B8=D1=88=D0=B5:
> > Current KVM does not expect L1 hypervisor to allow L2 guest to access
> > APIC page directly when APICv is enabled. When this happens, KVM
> > emulates the access itself resulting in interrupt lost.

Kinda stating the obvious, but as Maxim alluded to, emulating an APIC acces=
s while
APICv is active should not result in lost interrupts.  I.e. suppressing API=
Cv is
likely masking a bug that isn't unique to this specific scenario.

> Is there a good reason why KVM doesn't expose APIC memslot to a nested gu=
est?

AFAIK, simply because no one has ever requested that KVM support such a use=
 case.

> While nested guest runs, the L1's APICv is "inhibited" effectively anyway=
, so
> writes to this memslot should update APIC registers and be picked up by A=
PICv
> hardware when L1 resumes execution.
>=20
> Since APICv alows itself to be inhibited due to other reasons, it means t=
hat
> just like AVIC, it should be able to pick up arbitrary changes to APIC
> registers which happened while it was inhibited, just like AVIC does.
>=20
> I'll take a look at the code to see if APICv does this (I know AVIC's cod=
e
> much better that APICv's)
>=20
> Is there a reproducer for this bug?

+1, this needs a reproducer, or at the very least a very detailed explanati=
on
and analysis.