Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 02, 2025, Igor Mammedov wrote:
> Or even better a single KVM optin feature 'do_not_advertise_features_not_supported_by_host_cpu',
> and then QEMU could use that for disabling all nonsense in one go.
> Plus all of that won't be breaking KVM ABI nor qemu had to add fixups for this and that feature.
> 
> After some time when old machine types are deprecated/gone, KVM could make it default and eventually
> remove advertising 'fake' features.

Such a feature/quirk wouldn't be useful in practice.  There are several features
that KVM emulates irrespective of hardware support, and that generally speaking
every VMM will want to enable whenever possible, e.g. x2APIC, TSC deadline timer,
TSC adjust, and the amusing "no SMM_CTL MSR" anti-feature.  Throwing out x2APIC
and TSC deadline timer in particular would be a significant regression, i.e. not
something any end user actually wants.

If QEMU or any other VMM wants to filter KVM's support against bare metal, then
QEMU can simply do CPUID itself.

Somewhat of a side topic, the somewhat confusingly-named KVM_GET_EMULATED_CPUID
exists to allow KVM to differentiate between features that KVM can emulate and/or
virtualize without additional overhead, and those that KVM can emulate but with
non-trivial cost.  E.g. KVM advertises MOVBE and RDPID in KVM_GET_SUPPORTED_CPUID
if and only if they are natively suppored, because enabling those instructions in
the guest's CPUID model turns exitless instruction execution into expensive #UD
VM-Exits and slow emulation.  But KVM unconditionally advertises support for them
in KVM_GET_EMULATED_CPUID so that userspace can run a "newer" VM on old hardware.

I mention KVM_GET_EMULATED_CPUID purely to stave off any exploration into trying
to move ARCH_CAPABILITIES to KVM_GET_EMULATED_CPUID.  Name aside, it's not the
correct fit (and would still be an ABI change).