On Tue, Jul 01, 2025, Konrad Rzeszutek Wilk wrote: > 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.liu@xxxxxxxxx> 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.li@xxxxxxxxx> > > > > 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. No, I agreed that KVM's behavior is pointless, annoying, and odd[*]. I do not agree that KVM's behavior is an outright bug. [*] https://lore.kernel.org/all/aF1S2EIJWN47zLDG@xxxxxxxxxx