On 8/3/20 10:16 AM, Andy Lutomirski wrote: > - TILE: genuinely per-thread, but it's expensive so it's > lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not > fully disambiguated from the other use of #NM. So it sort of works, > but it's gross. For those playing along at home, there's a new whitepaper out from Intel about some new CPU features which are going to be fun: > https://software.intel.com/content/dam/develop/public/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf Which part were you worried about? I thought it was fully disambuguated from this: > When XFD causes an instruction to generate #NM, the processor loads > the IA32_XFD_ERR MSR to identify the disabled state component(s). > Specifically, the MSR is loaded with the logical AND of the IA32_XFD > MSR and the bitmap corresponding to the state components required by > the faulting instruction. > > Device-not-available exceptions that are not due to XFD — those > resulting from setting CR0.TS to 1 — do not modify the IA32_XFD_ERR > MSR. So if you always make sure to *clear* IA32_XFD_ERR after handing and XFD exception, any #NM's with a clear IA32_XFD_ERR are from "legacy" CR0.TS=1. Any bits set in IA32_XFD_ERR mean a new-style XFD exception. Am I missing something? _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
