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 11:36, Ingo Molnar wrote:
> 
>> 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.

The worry boils down to code in the kernel or userspace doing this:

	if (XGETBV(0) & 0x11)
		do_mpx_gunk();

So, sure, we could try to make sure that new kernels don't have any
do_mpx_gunk() in them, but that doesn't help old kernels or other OSes/VMMs.

The only thing that would help them would be to hide the XFEATURES 3/4
enumeration and require some kind of opt-in for it so that it can't be
enabled except with APX-aware software. That's totally possible, of
course. But it doesn't fix the userspace problem.

If folks really look at the diffstat:

>  10 files changed, 108 insertions(+), 57 deletions(-)

and hate it with _so_ much of a passion that we should go back and re
architect this thing, just say the word. I don't know how far along the
hardware is, but this kind of stuff is usually fixable in microcode. We
can totally go back to the drawing board and try to reuse XFEATURES 3/4
and see if there are any showstoppers (like with "other" OSes).

Let's just make sure that we've got a strong consensus amongst the
maintainer team, and I'm happy to oblige!