Hi Thomas, > On Nov 19, 2021, at 2:13 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Jun, > > On Thu, Nov 18 2021 at 23:17, Jun Nakajima wrote: >> On Nov 17, 2021, at 4:53 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> >>> It doesn't have to happen in current processors, but it should be >>> architecturally valid behavior to clear the processor's state as soon >>> as a bit in XFD is set to 1. >> >> 3.3 RECOMMENDATIONS FOR SYSTEM SOFTWARE >> >> System software may disable use of Intel AMX by clearing XCR0[18:17], >> by clearing CR4.OSXSAVE, or by setting IA32_XFD[18]. It is recommended >> that system software initialize AMX state (e.g., by executing >> TILERELEASE) before doing so. This is because maintaining AMX state in >> a non-initialized state may have negative power and performance >> implications. >> >> System software should not use XFD to implement a “lazy restore” >> approach to management of the XTILEDATA state component. This approach >> will not operate correctly for a variety of reasons. One is that the >> LDTILECFG and TILERELEASE instructions initialize XTILEDATA and do not >> cause an #NM exception. Another is that an execution of XSAVE by a >> user thread will save XTILEDATA as initialized instead of the data >> expected by the user thread. > > Can this pretty please be reworded so that it says: > > When setting IA32_XFD[18] the AMX register state is not guaranteed to > be preserved. The resulting register state depends on the > implementation. > > Also it's a real design disaster that component 17 cannot be fenced off > via XFD. That's really inconsistent and leads exactly to this half > defined state. > I’ll work with the H/W team on those (i.e. rewording and the component 17 issue). Thanks, --- Jun
