Re: [PATCH 1/7] x86/fpu: Document signal frame layout and portability

[Borislav Petkov]

On Tue, Sep 08, 2026 at 04:34:21AM +0000, Andrei Vagin wrote:
> The x86 signal frame is designed to be self-describing, with the
> 'xstate_size' field in the software-reserved bytes indicating the actual
> size of the context. This design is required for portability, allowing a
> signal frame created on a system with a specific set of xstate features
> to be restored on a machine with a different (larger) set of features.
> 
> Document the signal frame software reserved bytes (struct _fpx_sw_bytes)
> and portability constraints in Documentation/arch/x86/xstate.rst, and
> add a summary and cross-reference in <uapi/asm/sigcontext.h>.

No need for that paragraph - that's describing the diff.

> Reviewed-by: Alexander Mikhalitsyn <alexander@xxxxxxxxxxxxx>
> Signed-off-by: Andrei Vagin <avagin@xxxxxxxxxx>
> ---
>  Documentation/arch/x86/xstate.rst      | 55 ++++++++++++++++++++++++++
>  arch/x86/include/uapi/asm/sigcontext.h | 14 +++++++
>  2 files changed, 69 insertions(+)
> 
> diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst
> index cec05ac464c1..92e5ff7dd6a2 100644
> --- a/Documentation/arch/x86/xstate.rst
> +++ b/Documentation/arch/x86/xstate.rst
> @@ -172,3 +172,58 @@ are extended to control the guest permission:
>  
>  Note that some VMMs may have already established a set of supported state
>  components. These options are not presumed to support any particular VMM.
> +
> +Signal Frame Layout and Portability
> +-----------------------------------
> +
> +The signal frame is designed to be self-describing and portable. This is
> +especially important for checkpoint/restore tools like CRIU, which may restore
> +a process on a different host than where it was checkpointed. A signal frame
> +created on a machine with fewer CPU features can be successfully restored on a
> +machine with more CPU features.

				... but not vice-versa.

> +Signal Frame Software Reserved Bytes
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...

> diff --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h
> index d0d9b331d3a1..d85226c67e19 100644
> --- a/arch/x86/include/uapi/asm/sigcontext.h
> +++ b/arch/x86/include/uapi/asm/sigcontext.h
> @@ -34,6 +34,20 @@
>   * fpstate+extended_size-FP_XSTATE_MAGIC2_SIZE address) is set to
>   * FP_XSTATE_MAGIC2 so that you can sanity check your size calculations.)
>   *
> + * The xstate_size field indicates the actual size of the xstate context
> + * (including the 512-byte FXSAVE area and the 64-byte XSAVE header
> + * struct _header). This size is used in conjunction with the pointer to
> + * the xstate context to locate FP_XSTATE_MAGIC2. In 64-bit signal frames,
> + * the fpstate pointer points directly to the xstate context. In 32-bit
> + * signal frames (including 32-bit compat tasks on 64-bit kernels), the
> + * fpstate pointer points to a legacy 112-byte FPU environment
> + * (struct _fpstate_32) that precedes the xstate context, so the xstate
> + * context starts at fpstate + 112.

Break that one into two paragraphs for easier reading:

 * The xstate_size field indicates the actual size of the xstate context
 * (including the 512-byte FXSAVE area and the 64-byte XSAVE header
 * struct _header). This size is used in conjunction with the pointer to
 * the xstate context to locate FP_XSTATE_MAGIC2.
 *
 * In 64-bit signal frames, the fpstate pointer points directly to the xstate
 * context. In 32-bit signal frames (including 32-bit compat tasks on 64-bit
 * kernels), the fpstate pointer points to a legacy 112-byte FPU environment
 * (struct _fpstate_32) that precedes the xstate context, so the xstate
 * context starts at fpstate + 112.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette