Re: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table and accessor macro

[Dave Hansen <dave.hansen@intel.com>]

On 2/27/25 12:29, Ingo Molnar wrote:
> My '#4' suggestion:
> 
>  - On bootup the CPU would not have the MPX/AVX bit enabled. So old 
>    host kernels are fine as-is.

Could you be specific about "the MPX bit"? Because, first of all, there
are a lot more than one bit in play here:
	
 * The MPX state enumeration in CPUID.0DH:EAX[3:4]
 * The MPX state enabling in XCR0[3:4]
 * The MPX ISA enumeration CPUID.07H:EBX[14]

As far as the architecture goes, those XSAVE enabling/enumeration bits
are rather independent from the _additional_ X86_FEATURE_MPX ISA CPUID bit.

Like I showed in my earlier example, the CPU enumerates which XSAVE
features are available. These enumeration bits in CPUID leaf 0xd *ARE*
set at boot independent of any other enabling or enumeration. In this
regard, XSAVE enumeration is quite independent of the other parts of the
ISA. This could, in theory, be changed to become dependent on some kind
of APX enabling. But that would be novel for an XSAVE feature.

Right now, the entirety of CPUID.0DH:EAX/EDX is static. It does not
change based on enumeration or other enabling. It can literally come out
of the microcode ROM.

So are you proposing that CPUID.0DH:EAX[3:4] would be 0x0 or 0x3 at CPU
reset? Or, that CPUID.0DH:EAX[3:4] would default to 0x0 at reset and
then flip to 0x3 based on some other kind of novel APX opt-in?

(BTW, CPUID.0DH:EAX[3:4]==0x3 on all MPX hardware)

>  - On new, AVX-aware host kernels, the AVX boot code enables the APX 
>    bit (via a ususal CPUID discovery mechanism), which is the same as 
>    the old MPX bit.

I think, here, you're suggesting that the new host kernel would set
XCR0[3:4]==0x3. Right?