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

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 7/1/2025 8:12 PM, Alexandre Chartre wrote:
> 
> On 7/1/25 13:12, Xiaoyao Li wrote:
>> 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.
>>
>> KVM and QEMU are not supposed to be blamed.
> 
> I can understand the Windows code logic, and I don't think it is 
> necessarily wrong,
> because it finds that the system has:
> 
> - an AMD cpu
> - an Intel-only feature/MSR
> 
> Then what should the code do? Trust the cpu type (AMD) or trust the MSR 
> (Intel).
> They decided not to choose, and for safety they stop because they have 
> an unexpected
> configuration.

It's not how software/OS is supposed to work with x86 architecture.

Though there are different vendors for x86, like Intel and AMD, they 
both implement x86 architecture. For x86 architecture, architectural 
features are enumerated by CPUID. If you read Intel SDM and AMD APM, you 
will find that Intel defines most features at range [0, x] while AMD 
defines most features at range [0x8000 000, 0x8000 000y]. But if a bit 
is defined by both Intel and AMD, it must have same meaning and 
enumerate the same feature.

Usually, a feature is first introduced by one vendor, then other vendors 
might implement the same one later. E.g., bus lock detection, which is 
enumerated via CPUID.7_0:ECX[bit 24] and first introduced by Intel in 
2020. Later, AMD implemented the same one from Zen 5. Before AMD 
implemented it, it was an Intel-only feature. Can we make code as below

    if (is_AMD && cpuid_enumerates_bus_lock_detect)
	error(unsupported CPU);

at that time? If we wrote such code, then it will fail on all the AMD 
Zen 5 CPUs.

Besides, I would like to talk about how software is supposed to deal 
with reserved bits on x86 architecture. In general, software should not 
set any expectation on the reserved bit. The value cannot be relied upon 
to be 0 since any reserved bit can have a meaning in the future. As Igor 
said:

   software shouldn't even try to use it or make any decisions
   based on that

For more information, you can refer to Intel SDM vol1. chapter 1.3.2 
Reserved Bits and Software compatibility. For AMD APM, you would need 
search yourself.

OK, back to the original question "what should the code do?"

My answer is, it can behave with any of below option:

- Be vendor agnostic and stick to x86 architecture. If CPUID enumerates 
a feature, then the feature is available architecturally.

- Based on AMD spec. Ignore the bit since it's a reserved bit. (Expect a 
reserved bit to be zero if not explicitly state by spec is totally wrong!)

> alex.
>