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

[Sean Christopherson <seanjc@google.com>]

On Thu, Feb 27, 2025, Dave Hansen wrote:
> On 2/27/25 13:37, Ingo Molnar wrote:
> ...
> >> 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.
> 
> Yeah, so with your proposal, we could toss out most of this series, so
> roughly 100 lines of code.
> 
> The downsides are:
> 
>  1. It can still confuse userspace, arguably in an architecture
>     violating manner because the SDM says: "If XCR0[4:3] is 11b, the
>     XSAVE feature set can be used to manage MPX state and software can
>     execute Intel MPX instructions." (this would be for userspace)
>    1a. Userspace like GDB still needs code to disambiguate XCR0[3:4]
>  2. It would add complexity in the XSAVE enumeration microcode. CPUID
>     data that comes right out of a ROM today would need to check some
>     CPU enabling state and change the enumeration.
>  3. Linux would still need to go fix up KVM in the kernel, like:
>     https://hansen.beer/~dave/intel/mpxapx.patch . Every APX-enabling
>     VMM would need something similar.
> 
> KVM folks, would you have any issues if XCR0[3:4] (the old MPX bits) got
> used for this new APX feature?

Yes.  I could live with complexity in KVM code, but I agree 100% with Andrew's
take:

  : XGETBV(0) & 0x18 in userspace has a very well defined meaning that is
  : MPX and not "MPX now but something unrelated in the future".

The risk of breaking guest kernels and guest userspace is decidedly non-zero.