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? 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
