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

["Enrico Weigelt, metux IT consult" <lkml@metux.net>]

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@oldenburg.str.redhat.com/>
>>> FWIW, I didn't receive it, because you excluded
>>> linux-kernel@vger.kernel.org
>>
>> 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@metux.net -- +49-151-27565287