Re: [PATCH 01/10] x86/fpu: Document signal frame portability

Am Mo., 15. Juni 2026 um 21:37 Uhr schrieb Andrei Vagin <[email protected]>:
>
> 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 this contract in the uabi headers and Documentation/. This
> requirement is critical for checkpoint/restore tools like CRIU, which
> should be able to migrate processes across machines with heterogeneous
> FPU capabilities. Note that portability is generally limited to CPUs
> from the same vendor (e.g., Intel vs. AMD) due to potential differences
> in xstate layouts.
>
> Signed-off-by: Andrei Vagin <[email protected]>

Reviewed-by: Alexander Mikhalitsyn <[email protected]>

> ---
>  Documentation/arch/x86/xstate.rst      | 13 +++++++++++++
>  arch/x86/include/uapi/asm/sigcontext.h | 13 +++++++++++++
>  2 files changed, 26 insertions(+)
>
> diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst
> index cec05ac464c1..facd97b26bf1 100644
> --- a/Documentation/arch/x86/xstate.rst
> +++ b/Documentation/arch/x86/xstate.rst
> @@ -172,3 +172,16 @@ 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 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.
> +
> +Note that signal frame portability is generally guaranteed only between CPUs
> +from the same vendor. Different vendors may use different offsets for the same
> +xstate features in the xsave area, making frames incompatible between them.
> diff --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h
> index d0d9b331d3a1..d52313345f21 100644
> --- a/arch/x86/include/uapi/asm/sigcontext.h
> +++ b/arch/x86/include/uapi/asm/sigcontext.h
> @@ -34,6 +34,19 @@
>   * 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 fxregs_state and xstate_header). This size is used in
> + * conjunction with the pointer to the xstate context to locate
> + * FP_XSTATE_MAGIC2. Note that on 32-bit systems, the fpstate pointer points
> + * to a legacy struct fregs_state (112 bytes) that precedes the xstate
> + * context, so the xstate context starts at fpstate + 112. This makes
> + * the signal frame self-describing and portable: a signal frame created on a
> + * machine with a certain set of xstate features can be restored on a machine
> + * with a different (larger) set of features, as long as the latter supports
> + * all features present in the frame. Note that this portability is generally
> + * limited to CPUs of the same vendor, as different vendors may use different
> + * xstate layouts.
> + *
>   * This extended area typically grows with newer CPUs that have larger and
>   * larger XSAVE areas.
>   */
> --
> 2.54.0.1189.g8c84645362-goog
>
>