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

[Ingo Molnar <mingo@kernel.org>]

* Chang S. Bae <chang.seok.bae@intel.com> wrote:

> The kernel has largely assumed that higher xstate component numbers
> correspond to later offsets in the buffer. However, this assumption does
> not hold for the non-compacted format, where a newer state component may
> have a lower offset.
> 
> When iterating over xstate components in offset order, using the feature
> number as an index may be misleading. At the same time, the CPU exposes
> each component’s size and offset based on its feature number, making it a
> key for state information.
> 
> To provide flexibility in handling xstate ordering, add a mapping table:
> feature order -> feature number. This new array stores feature numbers in
> offset order, accompanied by an accessor macro.
> 
> The macro enables sequential traversal of xstate components based on
> their actual buffer positions, given a feature bitmask. This will be
> particularly useful for computing customized non-compacted format sizes
> and sequentially accessing xstate offsets over non-compacted buffers.
> 
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
> ---
> This lays the groundwork for handling APX, which has feature number 19
> but appears immediately after FEATURE_YMM, occupying the space previously
> reserved for the now-deprecated MPX state.

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?

What's the scope of MPX support in actual processors out in the wild?

Thanks,

	Ingo