Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Merge tag 'x86_fpu_for_6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fpu updates from Dave Hansen:
"There's no _actual_ kernel functionality here.
This expands the documentation around AMX support including some code
examples. The example code also exposed the fact that hardware
architecture constants as part of the ABI, but there's no easy place
that they get defined for apps. Adding them to a uabi header will
eventually make life easier for consumers of the ABI.
Summary:
- Improve AMX documentation along with example code
- Explicitly make some hardware constants part of the uabi"
* tag 'x86_fpu_for_6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
Documentation/x86: Explain the state component permission for guests
Documentation/x86: Add the AMX enabling example
x86/arch_prctl: Add AMX feature numbers as ABI constants
Documentation/x86: Explain the purpose for dynamic features
+103
+100
Documentation/arch/x86/xstate.rst
+100
Documentation/arch/x86/xstate.rst
···
11
11
trapped by the kernel because by default the required large XSTATE buffers
12
12
are not allocated automatically.
13
13
14
+
The purpose for dynamic features
15
+
--------------------------------
16
+
17
+
Legacy userspace libraries often have hard-coded, static sizes for
18
+
alternate signal stacks, often using MINSIGSTKSZ which is typically 2KB.
19
+
That stack must be able to store at *least* the signal frame that the
20
+
kernel sets up before jumping into the signal handler. That signal frame
21
+
must include an XSAVE buffer defined by the CPU.
22
+
23
+
However, that means that the size of signal stacks is dynamic, not static,
24
+
because different CPUs have differently-sized XSAVE buffers. A compiled-in
25
+
size of 2KB with existing applications is too small for new CPU features
26
+
like AMX. Instead of universally requiring larger stack, with the dynamic
27
+
enabling, the kernel can enforce userspace applications to have
28
+
properly-sized altstacks.
29
+
14
30
Using dynamically enabled XSTATE features in user space applications
15
31
--------------------------------------------------------------------
16
32
···
80
64
state can be context switched. In the unlikely cases that the allocation
81
65
fails, the kernel sends SIGSEGV.
82
66
67
+
AMX TILE_DATA enabling example
68
+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
69
+
70
+
Below is the example of how userspace applications enable
71
+
TILE_DATA dynamically:
72
+
73
+
1. The application first needs to query the kernel for AMX
74
+
support::
75
+
76
+
#include <asm/prctl.h>
77
+
#include <sys/syscall.h>
78
+
#include <stdio.h>
79
+
#include <unistd.h>
80
+
81
+
#ifndef ARCH_GET_XCOMP_SUPP
82
+
#define ARCH_GET_XCOMP_SUPP 0x1021
83
+
#endif
84
+
85
+
#ifndef ARCH_XCOMP_TILECFG
86
+
#define ARCH_XCOMP_TILECFG 17
87
+
#endif
88
+
89
+
#ifndef ARCH_XCOMP_TILEDATA
90
+
#define ARCH_XCOMP_TILEDATA 18
91
+
#endif
92
+
93
+
#define MASK_XCOMP_TILE ((1 << ARCH_XCOMP_TILECFG) | \
94
+
(1 << ARCH_XCOMP_TILEDATA))
95
+
96
+
unsigned long features;
97
+
long rc;
98
+
99
+
...
100
+
101
+
rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
102
+
103
+
if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE)
104
+
printf("AMX is available.\n");
105
+
106
+
2. After that, determining support for AMX, an application must
107
+
explicitly ask permission to use it::
108
+
109
+
#ifndef ARCH_REQ_XCOMP_PERM
110
+
#define ARCH_REQ_XCOMP_PERM 0x1023
111
+
#endif
112
+
113
+
...
114
+
115
+
rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA);
116
+
117
+
if (!rc)
118
+
printf("AMX is ready for use.\n");
119
+
120
+
Note this example does not include the sigaltstack preparation.
121
+
83
122
Dynamic features in signal frames
84
123
---------------------------------
85
124
···
143
72
non-dynamic features which are always written regardless of their
144
73
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
145
74
field to determine if a features was written.
75
+
76
+
Dynamic features for virtual machines
77
+
-------------------------------------
78
+
79
+
The permission for the guest state component needs to be managed separately
80
+
from the host, as they are exclusive to each other. A coupled of options
81
+
are extended to control the guest permission:
82
+
83
+
-ARCH_GET_XCOMP_GUEST_PERM
84
+
85
+
arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features);
86
+
87
+
ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it
88
+
provides the same semantics and functionality but for the guest
89
+
components.
90
+
91
+
-ARCH_REQ_XCOMP_GUEST_PERM
92
+
93
+
arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr);
94
+
95
+
ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the
96
+
same semantics for the guest permission. While providing a similar
97
+
functionality, this comes with a constraint. Permission is frozen when the
98
+
first VCPU is created. Any attempt to change permission after that point
99
+
is going to be rejected. So, the permission has to be requested before the
100
+
first VCPU creation.
101
+
102
+
Note that some VMMs may have already established a set of supported state
103
+
components. These options are not presumed to support any particular VMM.
+3
arch/x86/include/uapi/asm/prctl.h
+3
arch/x86/include/uapi/asm/prctl.h