On Tue, Jul 01, 2025 at 03:05:00PM +0200, Igor Mammedov wrote: > On Tue, 1 Jul 2025 20:36:43 +0800 > Zhao Liu <zhao1....@intel.com> wrote: > > > On Tue, Jul 01, 2025 at 07:12:44PM +0800, Xiaoyao Li wrote: > > > Date: Tue, 1 Jul 2025 19:12:44 +0800 > > > From: Xiaoyao Li <xiaoyao...@intel.com> > > > Subject: Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised > > > on AMD > > > > > > 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. > > 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.
