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.