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 11:05, Ingo Molnar wrote:
> > So why not just reuse the MPX feature number and have some sort of 
> > extended feature bit that tells us and userspace that it's APX? The 
> > xsave area is getting reused anyway - causing all this indirection and 
> > trouble ...
> > 
> > Since we don't really do much for MPX in the kernel, and APX is not 
> > supposed to be used by the kernel either, it should be pretty much a 
> > shoe-in, right?
> 
> Theoretically, yes.
> 
> In practice, no.
> 
> MPX didn't have hardware enabling separate from the XSAVE enabling. So
> there is software out there that assumes that if it can see the MPX bits
> set in XCR0 that MPX is around. Take a look at kvm_mpx_supported() as an
> example. Would you be comfortable having an old kernel which had
> kvm_mpx_supported()==1 and X86_FEATURE_MPX==0? What about other VMMs?

I'd absolutely be comfortable if the APX bit was only enabled by newer, 
APX-aware kernels. Older kernels would see a non-MPX CPU and would 
handle it properly.

I really don't see the issue:

> There were basically three choices:
> 
>  1. Reuse XFEATURES 3/4 (MPX)
>  2. Create a new out-of-order XFEATURE 19 that reuses MPX space
>  3. Create a n in-order XFEATURE 19 that needs XFD and an opt-in
> 
> #1 risks breaking old MPX code in weird ways.

This is a false trichotomy. ;-)

There's a 4th option:

   4. Reuse XFEATURES 3/4 (MPX) only on APX-aware kernels, keep it 
      disabled for old kernels.

Problem solved.

> Is that what you were asking?

Yeah, thanks!

Thanks,

	Ingo