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

[Chang S. Bae]

On 6/15/2026 12:37 PM, Andrei Vagin wrote:
> +
> +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.


For XSTATE, I think the kernel is constrainted by the XSAVE architecture 
because it adopts the hardware-defined format directly.

This statement was once true before APX. With APX, however, an XSAVE 
image from older Intel MPX systems cannot be migrated directly to a 
newer Intel system where that region has been repurposed for APX.

Historically, newer XSTATE components happened to be introduced at 
higher offsets, and the kernel once had that assumption. However, that 
isn't an architectural guarantee ever. Commit 031b33ef1a6a 
("x86/fpu/xstate: Remove xstate offset check") clarified that fact 
before APX.

Similarly, although AMX significantly increased the XSAVE size, it is 
also impractical to assume the XSAVE image can continue growing 
indefinitely given the context-switching overheads.

If higher offsets were a strict architectural requirement, every future 
state would effectively need to become another XFD-backed dynamic state, 
which would also mandate larger frame size regardless of its actual use.

Given that all, repurposing deprecated region for new states seems to be 
an option in the architecture evolution. If so, the doc may want to 
clarify that the portability is constrained by the architectural XSAVE 
layout (even within same vendor).

Thanks,
Chang