Re: [PATCH 1/2] Documentation/x86: Add the AMX enabling example

From: Dave Hansen
Date: Thu Jun 16 2022 - 18:45:43 EST


> + 1. **Check the feature availability**. AMX_TILE is enumerated in CPUID
> + leaf 7, sub-leaf 0, bit 24 of EDX. If available, ``/proc/cpuinfo``
> + shows ``amx_tile`` in the flag entry of the CPUs. Given that, the
> + kernel may have set XSTATE component 18 in the XCR0 register. But a
> + user needs to ensure the kernel support via the ARCH_GET_XCOMP_SUPP
> + option::

Why did you bother mentioning the XCR0 and CPUID specifics? We don't
want applications doing that, right?

> + #include <asm/prctl.h>
> + #include <sys/syscall.h>
> + #include <stdio.h>
> + #include <unistd.h>

^ Just from the appearance here there looks to be some spaces vs. tabs
inconsistency.

> + #define ARCH_GET_XCOMP_SUPP 0x1021
> +
> + #define XFEATURE_XTILECFG 17
> + #define XFEATURE_XTILEDATA 18
> + #define XFEATURE_MASK_XTILE ((1 << XFEATURE_XTILECFG) | (1 << XFEATURE_XFILEDATA))
> +
> + unsigned long features;
> + long rc;
> +
> + ...
> +
> + rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
> +
> + if (!rc && features & XFEATURE_MASK_XTILE == XFEATURE_MASK_XTILE)
> + printf("AMX is available.\n");
> +
> + 2. **Request permission**. Now it is found that the kernel supports the
> + feature. But the permission is not automatically given. A user needs
> + to explicitly request it via the ARCH_REQ_XCOMP_PERM option::

That phrasing is a bit awkward. How about:

After determining support for AMX, an application must
explicitly ask permission to use it:
...

> + #define ARCH_REQ_XCOMP_PERM 0x1023
> +
> + ...
> +
> + rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, XFEATURE_XTILEDATA);
> +
> + if (!rc)
> + printf("AMX is ready for use.\n");
> +
> +Note this example does not include the sigaltstack preparation.
> +
> Dynamic features in signal frames
> ---------------------------------
>