> On Mar 29, 2021, at 9:39 AM, Len Brown <lenb@xxxxxxxxxx> wrote: > > >> >> In particular, the library may use instructions that main() doesn't know exist. > > And so I'll ask my question another way. > > How is it okay to change the value of XCR0 during the run time of a program? > > I submit that it is not, and that is a deal-killer for a request/release API. > > eg. main() doesn't know that the math library wants to use AMX, > and neither does the threading library. So main() doesn't know to > call the API before either library is invoked. The threading library starts up > and creates user-space threads based on the initial value from XCR0. > Then the math library calls the API, which adds bits to XCRO, > and then the user-space context switch in the threading library corrupts data > because the new XCR0 size doesn't match the initial size. > In the most extreme case, userspace could require that every loaded DSO be tagged with a new ELF note indicating support for dynamic XCR0 before changing XCR0. I would like to remind everyone that kernel enablement of AVX512 *already* broke old userspace. AMX will further break something. At least with dynamic XCR0 we can make the breakage opt-in. The ISA could have helped here by allowing the non-compacted XSTATE format to be frozen even in the face of changing XCR0. But it didn’t. At the end of the day, we are faced with the fact that XSTATE is a poor design, and we have to make the best of it.
