Re: [RFC PATCH] KVM: x86: inhibit APICv upon detecting direct APIC access from L2

[Sean Christopherson <seanjc@google.com>]

On Mon, Aug 07, 2023, Maxim Levitsky wrote:
> У пн, 2023-08-07 у 15:26 +0900, Ake Koomsin пише:
> > 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 access while
APICv is active should not result in lost interrupts.  I.e. suppressing APICv 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 guest?

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 APICv
> hardware when L1 resumes execution.
> 
> Since APICv alows itself to be inhibited due to other reasons, it means that
> 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.
> 
> I'll take a look at the code to see if APICv does this (I know AVIC's code
> much better that APICv's)
> 
> Is there a reproducer for this bug?

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