On Mon, Jul 07, 2025, Daniel P. Berrangé wrote: > On Tue, Jul 01, 2025 at 03:59:12PM -0400, Konrad Rzeszutek Wilk wrote: > > ..snip.. > > > OK, back to the original question "what should the code do?" > > > > > > My answer is, it can behave with any of below option: > > > > > > - Be vendor agnostic and stick to x86 architecture. If CPUID enumerates a > > > feature, then the feature is available architecturally. > > > > Exactly. That is what we believe Windows does. > > > > > > By this logic KVM is at fault for exposing this irregardless of the > > platform (when using -cpu host). And Sean (the KVM maintainer) agrees it is > > a bug. But he does not want it in the kernel due to guest ABI and hence > > the ask is to put this in QEMU. > > If QEMU unconditionally disables this on AMD, and a future AMD CPU > does implement it, then QEMU is now broken because it won't be fully > exposing valid features impl by the host CPU and supported by KVM. > > IOW, if we're going to have QEMU workaround the KVM mistake, then > the code change needs to be more refined. > > QEMU needs to first check whether the host CPU implements > ARCH_CAPABILITIES and conditionally disable it in the guest CPU > based on that host CPU check. Of course that would re-expose the > Windows guest bug, but that ceases to be KVM/QEMU's problem at > that point, as we'd be following a genuine physical CPU impl.
+1 In a perfect world, we'd quirk this in KVM. But to avoid a potentially breaking ABI change, KVM's quirky behavior would need to remain the default behavior, i.e. wouldn't actually help because QEMU would still need to be updated to opt out of the quirk. That, and KVM's quirk system is per-VM, whereas KVM_GET_SUPPORTED_CPUID is a /dev/kvm ioctl.
