Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: Thoughts of AMX KVM support based on latest kernel | Date | Fri, 19 Nov 2021 11:13:05 +0100 |
| |
Jun,
On Thu, Nov 18 2021 at 23:17, Jun Nakajima wrote: > On Nov 17, 2021, at 4:53 AM, Paolo Bonzini <pbonzini@redhat.com> 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.
Thanks,
tglx
| |