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

On Wed, Mar 31, 2021 at 3:28 PM Len Brown [off-list ref] wrote:

On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski [off-list ref] wrote:

quoted

But this whole annotation thing will require serious compiler support.
We already have problems with compilers inlining functions and getting confused about attributes.

We added compiler annotation for user-level interrupt handlers.
I'm not aware of it failing, or otherwise being confused.

I followed your link and found nothing. Can you elaborate?  In the
kernel, we have noinstr, and gcc gives approximately no help toward
catching problems.

Why would compiler support for fast-signals be any more "serious"?

quoted

An API like:

if (get_amx()) {
 use AMX;
} else {
 don’t;
}

Avoids this problem. And making XCR0 dynamic, for all its faults, at least helps force a degree of discipline on user code.

dynamic XCR0 breaks the installed base, I thought we had established that.

I don't think this is at all established.  If some code thinks it
knows the uncompacted XSTATE size and XCR0 changes, it crashes.  This
is not necessarily a showstopper.

We've also established that when running in a VMM, every update to
XCR0 causes a VMEXIT.

This is true, it sucks, and Intel could fix it going forward.

I thought the goal was to allow new programs to have fast signal handlers.
By default, those fast signal handlers would have a stable state
image, and would
not inherit large architectural state on their stacks, and could thus
have minimal overhead on all hardware.

That is *a* goal, but not necessarily the only goal.

--Andy