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

From: Enrico Weigelt, metux IT consult
Date: Wed Jun 30 2021 - 08:23:31 EST

On 28.06.21 14:49, Florian Weimer wrote:
* Enrico Weigelt:

On 24.06.21 01:11, Len Brown wrote:
x86 CPU features detection for applications (and AMX)
FWIW, I didn't receive it, because you excluded

me neither :(

Maybe just repost it to LKML ?

Isn't it sufficient to start Cc:ing the list?

Well, in that case people probably missed the original mail.
(maybe, I'm too lazy for searching the web for archives ... :P)

You mention the interface *was* designed with cpu features remaining
constant over a process' lifetime. Between the line I'm reading that
this might not be the case anymore.

How could that happen ? Process migration on a different CPU (or perhaps
on a different host) ?

AMX will be shown as enabled in the hardware, but trap into the kernel
on first use. The kernel developers prefer a model where it is checked
that the process has previously enabled the feature explicitly, instead
relying on lazy initialization as part of the trap (as intended by the
hardware design). This means that the usual CPUID/XCR0 approach (which
is reflected in the glibc feature) will not work.

Ah, now I'm beginning to get it:

* this feature needs to be initialized first, before it can be used
* on first use (when not initialized yet), it traps into the kernel
* we don't want to always initialize it at boot

Correct ?

What I'm wondering: why shall the process explicitly ask for it and
why isn't the initialization be done either on bootup or on first use ?

Damn, how could the cpu designers come up with such weird concepts
in the first place ? :o

It's not the CPU designers. The CPU behaves according to the old model.
(I consider the old model a success, despite all the challenges, but not
everyone agrees, obviosly.)

I'm still claiming already this old model is a horrible misdesign and
(most of) the extensions made over the decades are anything but well
designed - there had been many changes to do it much, much better.
For example there would have been ways to introduce new opcodes in a way
that they can be easily emulated in kernel or userland, w/o going
through a full trap.

But that's gonna be a long discussion on its own, probably getting
offtopic here.


Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287