Thanks Igor for looking here and thanks Konrad's explanation. > > > > On 7/1/2025 6:26 PM, Zhao Liu wrote: > > > > > > unless it was explicitly requested by the user. > > > > > But this could still break Windows, just like issue #3001, which > > > > > enables > > > > > arch-capabilities for EPYC-Genoa. This fact shows that even explicitly > > > > > turning on arch-capabilities in AMD Guest and utilizing KVM's emulated > > > > > value would even break something. > > > > > > > > > > So even for named CPUs, arch-capabilities=on doesn't reflect the fact > > > > > that it is purely emulated, and is (maybe?) harmful. > > > > > > > > It is because Windows adds wrong code. So it breaks itself and it's > > > > just the > > > > regression of Windows. > > > > > > Could you please tell me what the Windows's wrong code is? And what's > > > wrong when someone is following the hardware spec? > > > > the reason is that it's reserved on AMD hence software shouldn't even try > > to use it or make any decisions based on that. > > > > > > PS: > > on contrary, doing such ad-hoc 'cleanups' for the sake of misbehaving > > guest would actually complicate QEMU for no big reason. > > The guest is not misbehaving. It is following the spec.
(That's my thinking, and please feel free to correct me.) I had the same thought. Windows guys could also say they didn't access the reserved MSR unconditionally, and they followed the CPUID feature bit to access that MSR. When CPUID is set, it indicates that feature is implemented. At least I think it makes sense to rely on the CPUID to access the MSR. Just as an example, it's unlikely that after the software finds a CPUID of 1, it still need to download the latest spec version to confirm whether the feature is actually implemented or reserved. Based on the above point, this CPUID feature bit is set to 1 in KVM and KVM also adds emulation (as a fix) specifically for this MSR. This means that Guest is considered to have valid access to this feature MSR, except that if Guest doesn't get what it wants, then it is reasonable for Guest to assume that the current (v)CPU lacks hardware support and mark it as "unsupported processor". As Konrad's mentioned, there's the previous explanation about why KVM sets this feature bit (it started with a little accident): https://lore.kernel.org/kvm/CALMp9eRjDczhSirSismObZnzimxq4m+3s6Ka7OxwPj5Qj6X=b...@mail.gmail.com/#t So I think the question is where this fix should be applied (KVM or QEMU) or if it should be applied at all, rather than whether Windows has the bug. But I do agree, such "cleanups" would complicate QEMU, as I listed Eduardo as having done similar workaround six years ago: https://lore.kernel.org/qemu-devel/20190125220606.4864-1-ehabk...@redhat.com/ Complexity and technical debt is an important consideration, and another consideration is the impact of this issue. Luckily, newer versions of Windows are actively compatible with KVM + QEMU: https://blogs.windows.com/windows-insider/2025/06/23/announcing-windows-11-insider-preview-build-26120-4452-beta-channel/ But it's also hard to say if such a problem will happen again. Especially if the software works fine on real hardware but fails in "-host cpu" (which is supposed synchronized with host as much as possible). > > Also > > KVM does do have plenty of such code, and it's not actively preventing > > guests from using it. > > Given that KVM is not welcoming such change, I think QEMU shouldn't do that > > either. > > Because KVM maintainer does not want to touch the guest ABI. He agrees > this is a bug. If we agree on this fix should be applied on Linux virtualization stack, then the question of whether the fix should land in KVM or QEMU is a bit like the chicken and egg dilemma. I personally think it might be better to roll it out in QEMU first — it feels like the safer bet: * Currently, the -cpu host option enables this feature by default, and it's hard to say if anyone is actually relying on this emulated feature (though issue #3001 suggests it causes trouble for Windows). So only when the ABI changes, it's uncertain if anything will break. * Similarly, if only the ABI is changed, I'm a bit unsure if there's any migration based on "-cpu host" and between different versions of kernel. And, based on my analysis at the beginning reply, named CPUs also have the effect if user actively sets "arch-capbilities=on". But the key here point is the migration happens between different kernel versions. * Additionally, handling different versions of ABI can sometimes be quite complex. After changing the ABI, there might be differences between the new kernel and the old stable kernels (and according to doc, the oldest supported kernel is v4.5 - docs/system/target-i386.rst). It's similar to what Ewan previously complained about: https://lore.kernel.org/qemu-devel/53119b66-3528-41d6-ac44-df1666995...@zhaoxin.com/ So, if anyone is relying on the current emulated feature, changing the ABI will inevitably break existing things, and QEMU might have to bear the cost of maintaining compatibility with the old ABI. :-( Personally, I think the safer approach is to first handle potential old dependencies in QEMU through a compat option. Once the use case is eliminated in user space, it can clearly demonstrate that the ABI change won't disrupt user space. The workaround change I proposed to Alexandre isn't meant to be permanent. If we upgrade the supported kernel version to >6.17 (assuming the ABI can be changed in 6.17), then the workaround can be removed — though I admit that day might never come... Thanks for your patience. Zhao
