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

[Ingo Molnar <mingo@kernel.org>]

* Dave Hansen <dave.hansen@intel.com> wrote:

> On 2/27/25 12:02, Ingo Molnar wrote:
> >>> There's a 4th option:
> >>>
> >>>    4. Reuse XFEATURES 3/4 (MPX) only on APX-aware kernels, keep it 
> >>>       disabled for old kernels.
> >>>
> >>> Problem solved.
> >> The worry boils down to code in the kernel or userspace doing this:
> >>
> >> 	if (XGETBV(0) & 0x11)
> >> 		do_mpx_gunk();
> > New, APX-aware kernels wouldn't be doing this, why would they?
> 
> New, updated software is rarely the problem. It would not be a problem
> in this case either.
> 
> The problem is with old OSes/VMMs and even old userspace on new kernels.

So this is the 3rd time I have to repeat that if the MPX/AVX bit is 
disabled in the CPU by default on bootup, these old kernels will work 
fine just like they do today, so I think we might be talking past each 
other.

Let's try again:

> So I'm not _quite_ sure what you meant when you said:
> 
> > Old kernels would *never* see this bit enabled if it's disabled by
> > default on bootup ...
> 
> Because old kernel very much do see the MPX bits in CPUID and very 
> much do enable them by default via XSETBV.

My '#4' suggestion:

 - On bootup the CPU would not have the MPX/AVX bit enabled. So old 
   host kernels are fine as-is.

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

 - Likewise, the APX init code in APX-aware guest kernels would be able 
   to enable the APX bit as well. Old guest kernels will have the 
   APX/MPX bit disabled and will continue to work fine.

 - [ With this approach there's no out-of-order feature bit problem, 
     the APX feature bit lines up with the APX xsave area. Enabling AVX 
     would require very little code - only the CPUID discovery and MSR 
     twiddling to enable it in the FPU init path, plus similar KVM 
     code. ]

Thanks,

	Ingo