From: Andrei Vagin <avagin@google.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
"Chang S. Bae" <chang.seok.bae@intel.com>
Cc: linux-kernel@vger.kernel.org, criu@lists.linux.dev,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Andrei Vagin <avagin@google.com>,
Alexander Mikhalitsyn <alexander@mihalicyn.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH 1/7] x86/fpu: Document signal frame layout and portability
Date: Thu, 24 Sep 2026 04:15:57 +0000 [thread overview]
Message-ID: <20260924041604.3209659-2-avagin@google.com> (raw)
In-Reply-To: <20260924041604.3209659-1-avagin@google.com>
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.
Reviewed-by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Signed-off-by: Andrei Vagin <avagin@google.com>
---
Documentation/arch/x86/xstate.rst | 54 ++++++++++++++++++++++++++
arch/x86/include/uapi/asm/sigcontext.h | 15 +++++++
2 files changed, 69 insertions(+)
diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst
index cec05ac464c1..e2944f744255 100644
--- a/Documentation/arch/x86/xstate.rst
+++ b/Documentation/arch/x86/xstate.rst
@@ -172,3 +172,57 @@ 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
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+On CPUs supporting XSAVE, bytes 464..511 in the 512-byte FXSAVE/FXRSTOR frame
+are reserved for software use and contain ``struct _fpx_sw_bytes`` (defined in
+``<uapi/asm/sigcontext.h>``)::
+
+ struct _fpx_sw_bytes {
+ __u32 magic1;
+ __u32 extended_size;
+ __u64 xfeatures;
+ __u32 xstate_size;
+ __u32 padding[7];
+ };
+
+- ``magic1``: Set to ``FP_XSTATE_MAGIC1`` (``0x46505853U``) if an extended
+ xstate context is present; 0 for a legacy frame.
+- ``extended_size``: The total size allocated on the stack for the frame,
+ measured from the ``fpstate`` pointer. In 32-bit signal frames, this also
+ includes the 112-byte legacy FPU state prefix of ``struct _fpstate_32``.
+- ``xfeatures``: The mask of xstate features saved in the frame.
+- ``xstate_size``: The actual size of the xstate context for the enabled
+ features (including the 512-byte FXSAVE area and the 64-byte XSAVE header).
+
+The kernel uses ``xstate_size`` in conjunction with the pointer to the xstate
+context to locate the ``FP_XSTATE_MAGIC2`` (``0x46505845U``) marker right after
+the xstate context (at ``xstate_context + xstate_size``). 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 ``struct _fpstate_32``, which contains the 112-byte legacy
+FPU state followed by the 512-byte FXSR state (and any extended xstate). Since
+there is no standalone UAPI structure defined for just the 112-byte legacy
+state, the xstate context starts at ``fpstate + 112`` (and ``extended_size``
+spans the entire allocation from ``fpstate``).
+
+Portability Constraints
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Signal frame portability is constrained by the architectural XSAVE layout.
+Restoration is supported only if the destination host supports all features
+present in the frame and uses matching component offsets and sizes for them.
+While layout compatibility is generally maintained across CPUs from the same
+vendor, 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).
diff --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h
index d0d9b331d3a1..cff01406c0f4 100644
--- a/arch/x86/include/uapi/asm/sigcontext.h
+++ b/arch/x86/include/uapi/asm/sigcontext.h
@@ -34,6 +34,21 @@
* 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 struct _fpstate_32, which contains
+ * the 112-byte legacy FPU state followed by the 512-byte FXSR state (and any
+ * extended xstate), so the xstate context starts at fpstate + 112.
+ *
+ * This makes the signal frame self-describing and portable across machines
+ * with different xstate features. See Documentation/arch/x86/xstate.rst
+ * for details on signal frame portability and its architectural constraints.
+ *
* This extended area typically grows with newer CPUs that have larger and
* larger XSAVE areas.
*/
--
2.56.0.rc1.310.g51773c2048-goog
next prev parent reply other threads:[~2026-09-24 4:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 4:15 [PATCH v7 0/7] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-09-24 4:15 ` Andrei Vagin [this message]
2026-09-24 4:15 ` [PATCH 2/7] x86/fpu: Clean up and rename variables in signal frame handling Andrei Vagin
2026-09-24 4:15 ` [PATCH 3/7] x86/fpu: Extract restore_from_ia32_fxstate() and clean up fpu__restore_sig() Andrei Vagin
2026-09-24 4:16 ` [PATCH 4/7] x86/fpu: Document reasoning of FX-only fallback Andrei Vagin
2026-09-24 4:16 ` [PATCH 5/7] x86/fpu: Fix potential underflow in xstate_calculate_size() Andrei Vagin
2026-09-24 4:16 ` [PATCH 6/7] x86/fpu: Pre-fault only required size of xstate buffer Andrei Vagin
2026-09-24 4:16 ` [PATCH 7/7] selftests/x86: Add tests for signal frame FPU portability Andrei Vagin
2026-09-24 18:47 ` Borislav Petkov
2026-09-24 21:09 ` Andrei Vagin
-- strict thread matches above, loose matches on Subject: below --
2026-09-25 16:24 [PATCH v8.1 0/7] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-09-25 16:24 ` [PATCH 1/7] x86/fpu: Document signal frame layout and portability Andrei Vagin
2026-09-24 21:01 [PATCH v8 0/7] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-09-24 21:01 ` [PATCH 1/7] x86/fpu: Document signal frame layout and portability Andrei Vagin
2026-09-16 23:23 [PATCH v6 0/7] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-09-16 23:23 ` [PATCH 1/7] x86/fpu: Document signal frame layout and portability Andrei Vagin
2026-09-08 4:34 [PATCH v5 0/7] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-09-08 4:34 ` [PATCH 1/7] x86/fpu: Document signal frame layout and portability Andrei Vagin
2026-09-16 4:53 ` Borislav Petkov
2026-09-16 15:31 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260924041604.3209659-2-avagin@google.com \
--to=avagin@google.com \
--cc=alexander@mihalicyn.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=criu@lists.linux.dev \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.