Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

[Dave Hansen]

On 3/27/21 5:53 PM, Thomas Gleixner wrote:
> Making it solely depend on XCR0 and fault if not requested upfront is
> bringing you into the situation that you broke 'legacy code' which
> relied on the CPUID bit and that worked until now which gets you
> in the no-regression trap.

Trying to find the right place to jump into this thread... :)

I don't know what apps do in practice.  But, the enumeration of the
features in the SDM describes three steps:
1. Check for XGETBV support
2. Use XGETBV[0] to check that the OS is aware of the feature and is
   context-switching it
3. Detect the feature itself

So, apps *are* supposed to be checking XCR0 via XGETBV.  If they don't,
they run the risk of a feature being supported by the CPU and the
registers "working" but not being context-switched.

Zeroing out bits in XCR0 will have the effect of telling the app that
the OS isn't context-switching the state.  I think this means that apps
will see the same thing in both situations:
1. If they run an old (say pre-AVX-512) kernel on new AVX-512-enabled
   hardware, or
2. They run a new kernel with this fancy proposed XCR0-switching
   mechanism

I _think_ that gets us off the hook for an ABI break, at least for AVX-512.