Re: [PATCH] i386/cpu: ARCH_CAPABILITIES should not be advertised on AMD

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@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.li@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.