Re: [PATCH v2] KVM: x86: Complain about an attempt to change the APIC base address

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 24, 2024, Jim Mattson wrote:
> On Wed, Jul 24, 2024 at 11:13 AM Maxim Levitsky <mlevitsk@redhat.com> wrote:
> > What if we introduce a new KVM capability, say CAP_DISABLE_UNSUPPORTED_FEATURES,
> > and when enabled, outright crash the guest when it attempts things like
> > changing APIC base, APIC IDs, and other unsupported things like that?
> >
> > Then we can make qemu set it by default, and if users have to use an
> > unsupported feature, they could always add a qemu flag that will disable
> > this capability.
> 
> Alternatively, why not devise a way to inform userspace that the guest
> has exercised an unsupported feature? Unless you're a hobbyist working on
> your desktop, kernel messages are a *terrible* mechanism for communicating
> with the end user.

A per-vCPU/VM stat would suffice in most cases, e.g. similar to the proposed
auto-EOI stat[*].  But I honestly don't see the point for APIC base relocation
and changing x2APIC IDs.  We _know_ these things don't work.  Having a flag might
save a bit of triage when debugging a guest issue, but I fail to see what userspace
would do with the information outside of a debug scenario.

And for APIC base relocation, userspace already has the ability to detect this
unuspported behavior.  Trap writes to MSR_IA32_APICBASE via MSR filtering, then
reflect the value back into KVM.  Performance would suck, but writes to
MSR_IA32_APICBASE should be very rare, especially if the host forces x2APIC via
guest firmware.

As for changing x2APIC IDs, that is the architectural behavior on Intel.  If a
kernel is trying to change x2APIC IDs, it's going to have a bad day regardless.

So I guess the question is, what motivated this patch?