Re: Revisiting XFD-based AMX and heterogenous systems

[Thomas Gleixner <tglx@linutronix.de>]

Andy,

On Mon, Nov 15 2021 at 11:59, Andy Lutomirski wrote:
> So I suggest that we go back and switch to the XCR0 model.  Tasks will
> start out with AMX clear in XCR0.  If they want AMX, they issue a
> prctl asking for AMX, AMX gets set in XCR0, and the tasks need to be
> able to tolerate the XCR0 change.

We can do that, but that still want's XFD for avoiding allocating large
buffers for all tasks in such a process which never use that feature.

Aside of that as we all know context switching XCR0 sucks.

> Then, if Intel ever wants to expose the full Alder Lake physical
> capabilities and support efficiency cores and AVX-512 on the same
> boot, we can have a mode in which tasks start with AVX-512 clear in
> XCR0 and can opt in with prctl.  This will require HPC-like apps to be
> recompiled or run with a special wrapper bit will otherwise expose the
> full HW capabilities. (Of course this assumes that Intel sets up MSRs
> or ucode or whatever to support this.)

If software needs to be recompiled or wrapped anyway then Intel can just
provide XFD support for AVX512 if it wants to expose this at runtime on
those CPUs.

As that needs to be implemented for AMX anyway the logical consequence
for user space is:

    available = arch_prctl(ARCH_GET_XCOMP_SUPP);        // Same as XCR0
    permitted = arch_prctl(ARCH_GET_XCOMP_PERM);        // XRC0 & permission bits

and work from there. If done with future XFD support for other features
than AMX in mind (even retroactively added for AVX512) then this should
be straight forward to adjust.

For the kernel adding XFD for AVX512 even conditionally based on a CPUID
bit is pretty straight forward now. It needs a small change to the way
how we distinguish XFD based and unconditional features, but that's
trivial effort compared to going for XCR0 switching with all its
downsides.

Thanks,

        tglx