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

[Enrico Weigelt, metux IT consult]

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)
> > > >     <https://lore.kernel.org/linux-api/87tulo39ms.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/>
> > > FWIW, I didn't receive it, because you excluded
> > > linux-kernel@xxxxxxxxxxxxxxx
> >
> > 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.


--mtx

--
---
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