From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f73.google.com (mail-oa1-f73.google.com [209.85.160.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC8993C0A1A for ; Tue, 26 May 2026 20:50:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779828658; cv=none; b=iz8SIS1r5ovbbutpXUxY+NMbrhICydgDeRXhHcUlt6qrCs8uiqTc9yJzmlBZrEyn3EoInwQGVdy5sEkMky8YUL6+UR7FTO+paChL/ar0mHimzhFtFrREQgFft5iMHOYwQIsV7GyiVtYJp/ORouP/SJrv0jQyBKwOkKg8AU5xvBs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779828658; c=relaxed/simple; bh=RXqO9/EzG7NHHVaTKdofiyf5ILbacGRreb6OiQJKfHU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=npqVEilcjIWJ/JzSBiy7Eu7JJM7f2AmvGwBvK1/UjUYo6kZx18kGle8eD0UtiaXsXEuPUeyCaJMJN+5+zX9VpdYzGHo/dnG4P8Z2r/mrZCeC0DxH1UBM5HOefXB7yOcB9GU+ZxOgYBACQQQBocG3EWM87XesZ/cL2qZAeBUEYGk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--avagin.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=d3SK5zbX; arc=none smtp.client-ip=209.85.160.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--avagin.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="d3SK5zbX" Received: by mail-oa1-f73.google.com with SMTP id 586e51a60fabf-4346755f7dcso19051041fac.3 for ; Tue, 26 May 2026 13:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779828656; x=1780433456; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=qKT8pYJkiGjUIO/shCncaMgJOtN4pdGcx5S8C39AkLs=; b=d3SK5zbXt7aqkyT26rWUWzlskPq2pspATYqulfVtXbf03UtqxkDEoIGaPvxh2Ti6NI OJbSplIaqgswBLHMMkbR4u6ylVyCWQjpUPn/PjDBAxf6Uwb/AHKCGG8MsJrCm1zai5OE npwCifrp4nM1du6jVeIpnVQhTUJLQae5he/8AFSf1p5erO9JQGm5smb/c0xySa04cpBw XOoIy0QmlLHVHyhG1XVlr8BNS0FBphfRjkjM7zAaY6QQlC/BI3CDfYfTUrpkds84S6j1 rvPgLomwwByGYzqQ5WB95UrAg+ZPu0i8jrm349AgaWQIIHARMvmAA99GFyCc7kpci8U8 t/pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779828656; x=1780433456; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qKT8pYJkiGjUIO/shCncaMgJOtN4pdGcx5S8C39AkLs=; b=ekRs0i4uqqB8d3eoUnYB4uaxMEGgZeid+gQDtBGaXUSSpN30ASJMbobMZbmbxg59UR r/i02/639eiHEC8vRUqpQFismYQRVgLZQYToSUjRNCqS60kWRmbKTQuj/8v1nIQGP9F7 ieSZJcHFz/Dog20Zrprxh8lVNnGWAGB9CKjxL60hRwLaVq4pr0aF/OYQvutdvLug5JSV AOqH4KahZXk/p9R1fBl0aYHIBL9B8hi+jKS0LNSSF2OMwM819FBXAbSdXVeui82UPTta 4nzNY9zQ+9al7ql13rdP3GoDQbq4vkM438JuUlT6vX4+3r9V2viVrF43ZwQCVizOktG3 UPUw== X-Gm-Message-State: AOJu0YxgNwJkDmC8jJOlohQ6bbEra1UMMQfdzNjEqZJP7ACSiKOYYl18 EGGNwWOx8Za+EGLJEw9gslZSyInuF0BKXmLrNdeoOvPSvH70MqPseRf+lqCgSzxLti6V2H/qBFf cQpvAJg== X-Received: from ilaf6.prod.google.com ([2002:a05:6e02:1686:b0:4fa:1fb0:8f75]) (user=avagin job=prod-delivery.src-stubby-dispatcher) by 2002:a4a:edca:0:b0:696:63bb:f004 with SMTP id 006d021491bc7-69d7ebc5c9amr10612696eaf.27.1779828655500; Tue, 26 May 2026 13:50:55 -0700 (PDT) Date: Tue, 26 May 2026 20:50:44 +0000 In-Reply-To: <20260526205047.3339490-1-avagin@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260526205047.3339490-1-avagin@google.com> X-Mailer: git-send-email 2.54.0.746.g67dd491aae-goog Message-ID: <20260526205047.3339490-3-avagin@google.com> Subject: [PATCH 2/5] x86/fpu: Document signal frame portability From: Andrei Vagin To: Thomas Gleixner , Ingo Molnar Cc: linux-kernel@vger.kernel.org, criu@lists.linux.dev, Borislav Petkov , Dave Hansen , x86@kernel.org, Andrei Vagin , "H. Peter Anvin" , "Chang S. Bae" Content-Type: text/plain; charset="UTF-8" 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 --- Documentation/arch/x86/xstate.rst | 14 ++++++++++++-- arch/x86/include/uapi/asm/sigcontext.h | 13 +++++++++++-- 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst index cec05ac464c1..e27e779bae44 100644 --- a/Documentation/arch/x86/xstate.rst +++ b/Documentation/arch/x86/xstate.rst @@ -170,5 +170,15 @@ are extended to control the guest permission: is going to be rejected. So, the permission has to be requested before the first VCPU creation. -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..f3d10f804f42 100644 --- a/arch/x86/include/uapi/asm/sigcontext.h +++ b/arch/x86/include/uapi/asm/sigcontext.h @@ -31,8 +31,17 @@ * If sw_reserved.magic1 == FP_XSTATE_MAGIC1 then there's a * sw_reserved.extended_size bytes large extended context area present. (The * last 32-bit word of this extended area (at the - * fpstate+extended_size-FP_XSTATE_MAGIC2_SIZE address) is set to - * FP_XSTATE_MAGIC2 so that you can sanity check your size calculations.) + * fpstate+xstate_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 to + * locate FP_XSTATE_MAGIC2. 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.746.g67dd491aae-goog