!220 Intel Advanced Matrix Extensions (AMX) support on SPR

	stifb=		[HW]

			Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]]

        strict_sas_size=

			[X86]

			Format: <bool>

			Enable or disable strict sigaltstack size checks

			against the required signal frame size which

			depends on the supported FPU features. This can

			be used to filter out binaries which have

			not yet been made aware of AT_MINSIGSTKSZ.

	sunrpc.min_resvport=

	sunrpc.max_resvport=

			[NFS,SUNRPC]

.. SPDX-License-Identifier: GPL-2.0

==================================

x86-specific ELF Auxiliary Vectors

==================================

This document describes the semantics of the x86 auxiliary vectors.

Introduction

============

ELF Auxiliary vectors enable the kernel to efficiently provide

configuration-specific parameters to userspace. In this example, a program

allocates an alternate stack based on the kernel-provided size::

   #include <sys/auxv.h>

   #include <elf.h>

   #include <signal.h>

   #include <stdlib.h>

   #include <assert.h>

   #include <err.h>

   #ifndef AT_MINSIGSTKSZ

   #define AT_MINSIGSTKSZ	51

   #endif

   ....

   stack_t ss;

   ss.ss_sp = malloc(ss.ss_size);

   assert(ss.ss_sp);

   ss.ss_size = getauxval(AT_MINSIGSTKSZ) + SIGSTKSZ;

   ss.ss_flags = 0;

   if (sigaltstack(&ss, NULL))

        err(1, "sigaltstack");

The exposed auxiliary vectors

=============================

AT_SYSINFO is used for locating the vsyscall entry point.  It is not

exported on 64-bit mode.

AT_SYSINFO_EHDR is the start address of the page containing the vDSO.

AT_MINSIGSTKSZ denotes the minimum stack size required by the kernel to

deliver a signal to user-space.  AT_MINSIGSTKSZ comprehends the space

consumed by the kernel to accommodate the user context for the current

hardware configuration.  It does not comprehend subsequent user-space stack

consumption, which must be added by the user.  (e.g. Above, user-space adds

SIGSTKSZ to AT_MINSIGSTKSZ.)

   x86_64/index

   sva

   sgx

   elf_auxvec

   xstate

Using XSTATE features in user space applications

================================================

The x86 architecture supports floating-point extensions which are

enumerated via CPUID. Applications consult CPUID and use XGETBV to

evaluate which features have been enabled by the kernel XCR0.

Up to AVX-512 and PKRU states, these features are automatically enabled by

the kernel if available. Features like AMX TILE_DATA (XSTATE component 18)

are enabled by XCR0 as well, but the first use of related instruction is

trapped by the kernel because by default the required large XSTATE buffers

are not allocated automatically.

Using dynamically enabled XSTATE features in user space applications

--------------------------------------------------------------------

The kernel provides an arch_prctl(2) based mechanism for applications to

request the usage of such features. The arch_prctl(2) options related to

this are:

-ARCH_GET_XCOMP_SUPP

 arch_prctl(ARCH_GET_XCOMP_SUPP, &features);

 ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of

 type uint64_t. The second argument is a pointer to that storage.

-ARCH_GET_XCOMP_PERM

 arch_prctl(ARCH_GET_XCOMP_PERM, &features);

 ARCH_GET_XCOMP_PERM stores the features for which the userspace process

 has permission in userspace storage of type uint64_t. The second argument

 is a pointer to that storage.

-ARCH_REQ_XCOMP_PERM

 arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr);

 ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled

 feature or a feature set. A feature set can be mapped to a facility, e.g.

 AMX, and can require one or more XSTATE components to be enabled.

 The feature argument is the number of the highest XSTATE component which

 is required for a facility to work.

When requesting permission for a feature, the kernel checks the

availability. The kernel ensures that sigaltstacks in the process's tasks

are large enough to accommodate the resulting large signal frame. It

enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent

sigaltstack(2) calls. If an installed sigaltstack is smaller than the

resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also,

sigaltstack(2) results in -ENOMEM if the requested altstack is too small

for the permitted features.

Permission, when granted, is valid per process. Permissions are inherited

on fork(2) and cleared on exec(3).

The first use of an instruction related to a dynamically enabled feature is

trapped by the kernel. The trap handler checks whether the process has

permission to use the feature. If the process has no permission then the

kernel sends SIGILL to the application. If the process has permission then

the handler allocates a larger xstate buffer for the task so the large

state can be context switched. In the unlikely cases that the allocation

fails, the kernel sends SIGSEGV.

Dynamic features in signal frames

---------------------------------

Dynamcally enabled features are not written to the signal frame upon signal

entry if the feature is in its initial configuration.  This differs from

non-dynamic features which are always written regardless of their

configuration.  Signal handlers can examine the XSAVE buffer's XSTATE_BV

field to determine if a features was written.

config HAVE_ARCH_NODE_DEV_GROUP

	bool

config DYNAMIC_SIGFRAME

	bool

source "kernel/gcov/Kconfig"

source "scripts/gcc-plugins/Kconfig"