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.
