Re: [PATCH 1/8] x86/fpu: Document signal frame portability

[Chang S. Bae]

On 8/16/2026 9:20 PM, 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 this contract in the uapi 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 constrained by the architectural XSAVE layout
> (component offsets and sizes); the destination machine must share
> matching component layouts for all features present in the frame. While
> layouts are consistent across CPUs from the same vendor for active
> features, differences can occur across vendors or if the XSAVE space of
> a deprecated feature (e.g. MPX) is repurposed for a newer feature
> (e.g. APX).

Thanks for including this detail.

>    * 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. Note that 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. 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 destination supports all features present in the frame
> + * and shares matching XSAVE component offsets and sizes for those features.
> + * Note that portability is constrained by the architectural XSAVE layout
> + * and is not guaranteed across different vendors or if space from
> + * deprecated features (e.g. MPX) is repurposed for newer features
> + * (e.g. APX).
Nit: the comment looks a bit large. It may be easier to follow if split 
into a few paragraphs. E.g. there are bits discussing the portability 
itself and that it is constrained by hardware.

  Reviewed-by: Chang S. Bae <chang.seok.bae@xxxxxxxxx>

Thanks,
Chang