← Documents Documentation/arch/x86/xstate.rst GitHub 원문 ↗

Linux 6.18.37 · Architecture

Using XSTATE Features in User Space Applications

동적 XSTATE 기능의 arch_prctl 권한, signal-stack 제약과 AMX·guest 사용 절차를 설명합니다.

Source pathDocumentation/arch/x86/xstate.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

xstate.rst:1-174

대형 XSTATE 기능은 기존 2KB signal stack 가정을 깨므로, kernel은 `arch_prctl(2)` 권한 요청과 altstack 크기 검사를 결합해 process별로 동적 활성화를 관리합니다.

`AMX TILE_DATA`는 지원 mask 확인, 권한 요청, 첫 instruction trap을 거쳐 task buffer가 확장됩니다. virtual machine guest 권한은 host와 분리되며 첫 `VCPU` 생성 전에 확정해야 합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 Using XSTATE features in user space applications
2 ================================================
3
4 The x86 architecture supports floating-point extensions which are
5 enumerated via CPUID. Applications consult CPUID and use XGETBV to
6 evaluate which features have been enabled by the kernel XCR0.
7
8 Up to AVX-512 and PKRU states, these features are automatically enabled by
9 the kernel if available. Features like AMX TILE_DATA (XSTATE component 18)
10 are enabled by XCR0 as well, but the first use of related instruction is
11 trapped by the kernel because by default the required large XSTATE buffers
12 are not allocated automatically.
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
30 Using dynamically enabled XSTATE features in user space applications
31 --------------------------------------------------------------------
32
33 The kernel provides an arch_prctl(2) based mechanism for applications to
34 request the usage of such features. The arch_prctl(2) options related to
35 this are:
36
37 -ARCH_GET_XCOMP_SUPP
38
39 arch_prctl(ARCH_GET_XCOMP_SUPP, &features);
40
41 ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of
42 type uint64_t. The second argument is a pointer to that storage.
43
44 -ARCH_GET_XCOMP_PERM
45
46 arch_prctl(ARCH_GET_XCOMP_PERM, &features);
47
48 ARCH_GET_XCOMP_PERM stores the features for which the userspace process
49 has permission in userspace storage of type uint64_t. The second argument
50 is a pointer to that storage.
51
52 -ARCH_REQ_XCOMP_PERM
53
54 arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr);
55
56 ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled
57 feature or a feature set. A feature set can be mapped to a facility, e.g.
58 AMX, and can require one or more XSTATE components to be enabled.
59
60 The feature argument is the number of the highest XSTATE component which
61 is required for a facility to work.
62
63 When requesting permission for a feature, the kernel checks the
64 availability. The kernel ensures that sigaltstacks in the process's tasks
65 are large enough to accommodate the resulting large signal frame. It
66 enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent
67 sigaltstack(2) calls. If an installed sigaltstack is smaller than the
68 resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also,
69 sigaltstack(2) results in -ENOMEM if the requested altstack is too small
70 for the permitted features.
71
72 Permission, when granted, is valid per process. Permissions are inherited
73 on fork(2) and cleared on exec(3).
74
75 The first use of an instruction related to a dynamically enabled feature is
76 trapped by the kernel. The trap handler checks whether the process has
77 permission to use the feature. If the process has no permission then the
78 kernel sends SIGILL to the application. If the process has permission then
79 the handler allocates a larger xstate buffer for the task so the large
80 state can be context switched. In the unlikely cases that the allocation
81 fails, the kernel sends SIGSEGV.
82
83 AMX TILE_DATA enabling example
84 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
85
86 Below is the example of how userspace applications enable
87 TILE_DATA dynamically:
88
89 1. The application first needs to query the kernel for AMX
90 support::
91
92 #include <asm/prctl.h>
93 #include <sys/syscall.h>
94 #include <stdio.h>
95 #include <unistd.h>
96
97 #ifndef ARCH_GET_XCOMP_SUPP
98 #define ARCH_GET_XCOMP_SUPP 0x1021
99 #endif
100
101 #ifndef ARCH_XCOMP_TILECFG
102 #define ARCH_XCOMP_TILECFG 17
103 #endif
104
105 #ifndef ARCH_XCOMP_TILEDATA
106 #define ARCH_XCOMP_TILEDATA 18
107 #endif
108
109 #define MASK_XCOMP_TILE ((1 << ARCH_XCOMP_TILECFG) | \
110 (1 << ARCH_XCOMP_TILEDATA))
111
112 unsigned long features;
113 long rc;
114
115 ...
116
117 rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
118
119 if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE)
120 printf("AMX is available.\n");
121
122 2. After that, determining support for AMX, an application must
123 explicitly ask permission to use it::
124
125 #ifndef ARCH_REQ_XCOMP_PERM
126 #define ARCH_REQ_XCOMP_PERM 0x1023
127 #endif
128
129 ...
130
131 rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA);
132
133 if (!rc)
134 printf("AMX is ready for use.\n");
135
136 Note this example does not include the sigaltstack preparation.
137
138 Dynamic features in signal frames
139 ---------------------------------
140
141 Dynamically enabled features are not written to the signal frame upon signal
142 entry if the feature is in its initial configuration. This differs from
143 non-dynamic features which are always written regardless of their
144 configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
145 field to determine if a features was written.
146
147 Dynamic features for virtual machines
148 -------------------------------------
149
150 The permission for the guest state component needs to be managed separately
151 from the host, as they are exclusive to each other. A coupled of options
152 are extended to control the guest permission:
153
154 -ARCH_GET_XCOMP_GUEST_PERM
155
156 arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features);
157
158 ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it
159 provides the same semantics and functionality but for the guest
160 components.
161
162 -ARCH_REQ_XCOMP_GUEST_PERM
163
164 arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr);
165
166 ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the
167 same semantics for the guest permission. While providing a similar
168 functionality, this comes with a constraint. Permission is frozen when the
169 first VCPU is created. Any attempt to change permission after that point
170 is going to be rejected. So, the permission has to be requested before the
171 first VCPU creation.
172
173 Note that some VMMs may have already established a set of supported state
174 components. These options are not presumed to support any particular VMM.
175

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

userspace XSTATE 기능 개요

1-12

x86 architecture는 `CPUID`로 열거하는 floating-point extension을 지원합니다. application은 `CPUID`를 조회하고 `XGETBV`를 사용해 kernel의 `XCR0`에서 어떤 기능이 활성화되었는지 평가합니다.

`AVX-512`와 `PKRU` state까지는 사용할 수 있는 경우 kernel이 자동으로 활성화합니다. `AMX TILE_DATA` 같은 기능(`XSTATE` component 18)도 `XCR0`로 활성화하지만, 필요한 대형 `XSTATE` buffer를 기본적으로 자동 할당하지 않으므로 관련 instruction의 첫 사용은 kernel trap을 일으킵니다.

동적 기능이 필요한 이유

13-28

기존 userspace library는 alternate signal stack 크기를 고정값으로 hard-code하는 경우가 많으며, 보통 2KB인 `MINSIGSTKSZ`를 흔히 사용합니다. 이 stack에는 kernel이 signal handler로 jump하기 전에 만드는 signal frame이 최소한 들어가야 하며, 그 frame에는 CPU가 정의한 `XSAVE` buffer가 포함되어야 합니다.

하지만 CPU마다 `XSAVE` buffer 크기가 다르므로 signal stack 크기는 정적이지 않고 동적입니다. 기존 application에 compile된 2KB는 `AMX` 같은 새 CPU 기능에 너무 작습니다. 모든 application에 더 큰 stack을 일괄 요구하는 대신, 동적 활성화를 통해 kernel은 userspace application이 올바른 크기의 altstack을 갖추도록 강제할 수 있습니다.

host XSTATE 권한 option

29-61

kernel은 application이 동적으로 활성화되는 기능의 사용을 요청할 수 있도록 `arch_prctl(2)` 기반 mechanism을 제공합니다. 관련 option은 다음과 같습니다.

`ARCH_GET_XCOMP_SUPP`는 지원되는 기능을 조회합니다.

arch_prctl(ARCH_GET_XCOMP_SUPP, &features);

결과는 `uint64_t` 형식의 userspace storage에 저장되며 두 번째 argument는 그 storage를 가리키는 pointer입니다.

`ARCH_GET_XCOMP_PERM`은 userspace process가 사용 권한을 가진 기능을 조회합니다.

arch_prctl(ARCH_GET_XCOMP_PERM, &features);

결과는 역시 `uint64_t` userspace storage에 저장되며 두 번째 argument가 그 storage의 pointer입니다.

`ARCH_REQ_XCOMP_PERM`은 동적으로 활성화되는 기능 또는 feature set의 사용 권한을 요청합니다.

arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr);

feature set은 `AMX` 같은 facility에 대응할 수 있고 하나 이상의 `XSTATE` component 활성화가 필요할 수 있습니다. `feature_nr` argument에는 facility 동작에 필요한 가장 높은 `XSTATE` component 번호를 전달합니다.

권한 검사와 첫 instruction trap

62-81

기능 권한을 요청하면 kernel은 availability를 확인하고 process의 각 task에 설치된 sigaltstack이 커진 signal frame을 담을 만큼 충분한지 검사합니다. 이 조건은 원문에 적힌 `ARCH_REQ_XCOMP_SUPP` 수행 시점과 이후의 모든 `sigaltstack(2)` call에서 강제됩니다.

이 문단의 `ARCH_REQ_XCOMP_SUPP` 표기는 앞에서 정의한 request option `ARCH_REQ_XCOMP_PERM`과 다릅니다. 원문 symbol을 그대로 보존했습니다.

상황kernel 결과
설치된 sigaltstack이 결과 signal frame보다 작음`ARCH_REQ_XCOMP_SUPP`가 `-ENOSUPP`를 반환
요청한 altstack이 허용된 기능에 비해 너무 작음`sigaltstack(2)`가 `-ENOMEM`을 반환
첫 관련 instruction 실행 시 권한 없음application에 `SIGILL` 전송
권한이 있고 대형 xstate buffer 할당 성공task state를 context switch할 수 있도록 buffer 확장
대형 xstate buffer 할당 실패application에 `SIGSEGV` 전송

부여된 권한은 process 단위로 유효합니다. `fork(2)`에서 상속되고 `exec(3)`에서 지워집니다. 동적 기능 관련 instruction을 처음 사용하면 kernel이 trap을 처리해 권한을 검사하고, 허용된 task에는 큰 state를 context switch할 수 있도록 더 큰 xstate buffer를 할당합니다.

AMX TILE_DATA 활성화 예

82-136

userspace application이 `TILE_DATA`를 동적으로 활성화하는 첫 단계는 kernel의 `AMX` 지원 여부를 조회하는 것입니다.

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

#ifndef ARCH_GET_XCOMP_SUPP
#define ARCH_GET_XCOMP_SUPP  0x1021
#endif

#ifndef ARCH_XCOMP_TILECFG
#define ARCH_XCOMP_TILECFG   17
#endif

#ifndef ARCH_XCOMP_TILEDATA
#define ARCH_XCOMP_TILEDATA  18
#endif

#define MASK_XCOMP_TILE      ((1 << ARCH_XCOMP_TILECFG) | \
                              (1 << ARCH_XCOMP_TILEDATA))

unsigned long features;
long rc;

...

rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);

if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE)
    printf("AMX is available.\n");

`ARCH_XCOMP_TILECFG` component 17과 `ARCH_XCOMP_TILEDATA` component 18을 결합한 `MASK_XCOMP_TILE`이 모두 지원되는지 확인한 뒤, application은 `TILE_DATA` 사용 권한을 명시적으로 요청해야 합니다.

#ifndef ARCH_REQ_XCOMP_PERM
#define ARCH_REQ_XCOMP_PERM  0x1023
#endif

...

rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA);

if (!rc)
    printf("AMX is ready for use.\n");

이 예제에는 `sigaltstack` 준비 과정이 포함되어 있지 않습니다.

signal frame의 동적 기능 state

137-145

동적으로 활성화된 기능이 initial configuration 상태라면 signal 진입 시 그 state를 signal frame에 기록하지 않습니다. configuration과 관계없이 항상 기록하는 비동적 기능과 다른 점입니다.

signal handler는 `XSAVE` buffer의 `XSTATE_BV` field를 조사해 특정 기능이 signal frame에 기록되었는지 판단할 수 있습니다.

virtual machine guest 권한

146-174

guest state component 권한은 host 권한과 서로 배타적이므로 별도로 관리해야 합니다. 다음 두 option이 guest 권한 제어를 위해 확장되었습니다.

`ARCH_GET_XCOMP_GUEST_PERM`은 `ARCH_GET_XCOMP_PERM`의 guest variant로, guest component에 대해 같은 semantics와 기능을 제공합니다.

arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features);

`ARCH_REQ_XCOMP_GUEST_PERM`은 `ARCH_REQ_XCOMP_PERM`의 guest variant이며 guest 권한에 같은 semantics를 적용합니다.

arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr);

기능은 유사하지만 제약이 있습니다. 첫 `VCPU`가 생성되는 순간 permission이 고정되며 그 이후의 변경 시도는 거부됩니다. 따라서 첫 `VCPU`를 만들기 전에 필요한 permission을 요청해야 합니다.

일부 `VMM`은 이미 지원할 state component 집합을 확정했을 수 있습니다. 이 option들은 특정 `VMM` 지원을 전제로 하지 않습니다.