Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return"

On Wed, Apr 29, 2026 at 12:26=E2=80=AFAM Chang S. Bae <chang.seok.bae@intel=
.com> wrote:
>
> On 4/28/2026 5:06 PM, Andrei Vagin wrote:
> >
> > The reverted commit broke applications that construct signal frames in
> > userspace (such as CRIU and gVisor) if the frame's xstate size is
> > smaller than the kernel's fpstate->user_size.
>
> In the extended state area, the sigframe embeds the hardware-defined
> XSAVE format. If CPU A and CPU B support different XSTATE features, the
> layout (size and offsets) differ across systems. However, within a
> system, the layout is invariant. Userspace can query CPUID to obtain the
> exact offset and sizes, which effectively defines the ABI.

I've been thinking about this more, and I believe the claim that XSAVE
offsets can differ across CPUs for the same feature is inaccurate. The
XSAVE standard format uses fixed offsets specifically to allow migration
between different CPU generations. If a feature exists on both the
source and destination CPUs, its data resides at the exact same byte
offset.

This design is what makes virtual machine migration possible.
Hypervisors cannot "translate" XSTATE data hidden in guest memory, so it
relies on these invariant offsets. The CRIU case is very similar: when a
process is in a signal handler, its state is saved on the stack as an
opaque block of memory.

If a future CPU uses different offsets for existing features, it would brea=
k
VM migration. Backward compatibility in this area should be a requirement
even for hardware. If we look at existing CPUs, they follow this principle.

Thanks,
Andrei