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

[Igor Mammedov <imammedo@redhat.com>]

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.

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.


> Do you expect software developers to make special modifications for QEMU
> after following the hardware spec? Or do you categorize this behavior as
> paravirtualization?
> 
> Resolving this issue within QEMU is already a win-win approach. I don't
> understand why you're shifting the blame onto Windows.
> 
> > KVM and QEMU are not supposed to be blamed.  
> 
> I do not think I'm blaming anything. So many people report
> this bug issue in QEMU community, and maintainer suggested a solution.
> 
> I totally agree on this way, and provide feedback to help thoroughly
> resolve the issue and prevent similar situations from happening again.
> 
> That's all.
> 
> Thanks,
> Zhao
> 
> 
>