Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

On Fri, May 21, 2021, at 12:10 PM, Thomas Gleixner wrote:

On Fri, May 21 2021 at 09:31, Andy Lutomirski wrote:

quoted

arch_prctl(SET_XSTATE_INIT_ON_FIRST_USE, TILE_STUFF);?

As long as this is allowed to fail, I don’t have a huge problem with
it.

I'm fine with that. It's still controlled by the OS and can return
-EPERM.

If allowed then the application would also accept to be insta killed if
that #NM allocation fails. Any bug report vs. that will be ignored.

quoted

I think several things here are regrettable:

1. Legacy XSTATE code might assume that XCR0 is a constant.

2. Intel virt really doesn’t like us context switching XCR0, although
we might say that this is Intel’s fault and therefore Intel’s
problem. AMD hardware doesn’t appear to have this issue.

3. AMX bring tangled up in XSTATE is unfortunate.  The whole XSTATE
mechanism is less than amazing.

IMO the best we can make of this whole situation is to make XCR0
dynamic, but the legacy compatibility issues are potentially
problematic.

Why? The bit can be enabled and #NM catches the violation of the ABI
contract if the application did not request usage. No XCR0 fiddling on
context switch required.

Thanks,

        tglx

XFD does nothing about signals.  It also doesn’t help give applications a non-Linux-specific way to ask if AMX is available. The SDM says that one can read XCR0.  Sure, we can use it, but cross platform libraries seem likely to get it wrong.