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

[Ingo Molnar]

* Dave Hansen <dave.hansen@xxxxxxxxx> wrote:

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

Yeah. That would be novel for an XSAVE feature - but so is the change 
in ordering. With my proposal we'd avoid the 
xfeature_noncompact_order[] indirection table AFAICS.

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

Yeah, I was thinking of a novel APX opt-in in the CPUID space, 
triggered via an MSR write or so, only triggered by APX-aware
host and guest kernels.

Old kernels would see 0 in all the legacy MPX state bits.

( Assuming this actually works for APX. )

Thanks,

	Ingo