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).
