From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f69.google.com (mail-oo1-f69.google.com [209.85.161.69]) (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 561C92FDC28 for ; Mon, 17 Aug 2026 04:20:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.69 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786940459; cv=none; b=sYn7Cj+s+eZmRJWladO0USC7AMGkx5a0ZmQRITCLDCo1haJDHcjCLmIeU9LQXZ0dklyMYrf7h/9y4afTIqaayI0mb7dsCAUfXdOTCaZNehqlmtKfTB2cmisWOy+LmKOlYfgVmXjQ7wqoZ1fCPG/9Xz2tHGUTkofWs4zk+l05pTs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786940459; c=relaxed/simple; bh=OsoKEk7GX9Uo57cVgZPnavKrdTxXv/aAd4HR3J1jAa4=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Xd3xBqUCJHbrS1gq4P6svSWD5jNE91AC5j+yGmdtH3vPasiYv0BAQCtUrAaN5c4tm9IvaZ+gJ1LFzLHd2nahlWHlkL2q79Rd7ffj+IWPb9tNbrtDBcQGjhvn08DMibHrvQ2sHK90lsUdfHoyot20VHQK7n0TndlwRSgJMVqEk8U= 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=A9YUvqAx; arc=none smtp.client-ip=209.85.161.69 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="A9YUvqAx" Received: by mail-oo1-f69.google.com with SMTP id 006d021491bc7-6acaccb8b0cso170797eaf.0 for ; Sun, 16 Aug 2026 21:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786940457; x=1787545257; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=NxGFNIIttK/Di7j6noyFdeWJnIK8feIGyqagdVJjeuU=; b=A9YUvqAxLHTeSKCqr98dFQSlXrAlyA2vhqAiPIZ0CHJJCWK2Lx6vBsP7lR6hCihWJI +gIASybpqh8y78xG6SmyGDdhywDjNDPoPc0nlRftVTxNgR+K1HQ1IZqexNIDsqyiRVq3 8p2Wdrcdt4dnfHrQsLwBnc8izdzSOlFW4Y83adaK9mMkrH/UKvD1W5oMtPXX9eiovb0L bAEZNLTmRmUMnpcmsxtblVxGPyJPR4TsyXfjwR+bzAto/N+KAQA4Kvhw3GNp5bMZtu3j fRONIcLnby1v75DQL8kc/MSUiZ7IIdSz9s29K0i+Ha9LJvmHLZ6jZNjPEBBo5NtGs9Yl J3xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786940457; x=1787545257; h=content-type: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:content-type; bh=NxGFNIIttK/Di7j6noyFdeWJnIK8feIGyqagdVJjeuU=; b=Kk17zc9jVlPRfVQ7LFZje4snOfD2qxvU/IS1dJ+zTJ/QFRyPVK+USFki/BaBPU5gXL NA0l/P8UPgsgpgiH2J2hFK0pztjJ30SlS+baInHY9RWq1X6cct/cxB7RhwNho7B+2Mbw gA6edQesw1Ggx21CFCnGKEvvJUce/mN5NiZ7ue3B69HlcYbeqmIKrCfBiTb/Xrr0qnph 7lfTzn824iYt/FEe57CDvI4WX4HxiV1+iaXCWic/OzoBlu1LYrOoggBaCKD7Eo4cdl8X 94IO0WSYwxb53dXUnZL5zbszHFdkdIdWT9uhc6NFl1S0VvdH0z7yo0J8RztbEAWc2pq0 4NZw== X-Gm-Message-State: AOJu0YzPfNQtnFI4iKIaeusc0yJeOV87J3DDS6A7IzMwocF6JPN2g+o5 CNp+7cvebQU9YQ6Hiw8QOXAhmJhe+dIxW09QUC7E+KKHw8WNKoXjy/BvuLI/goV69popGdlthbs VgPpN5g== X-Received: from iobbe8.prod.google.com ([2002:a05:6602:3788:b0:9a7:f0cb:c0ae]) (user=avagin job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6820:180c:b0:6a3:97a0:b224 with SMTP id 006d021491bc7-6b0d690c2b7mr20284657eaf.33.1786940456936; Sun, 16 Aug 2026 21:20:56 -0700 (PDT) Date: Mon, 17 Aug 2026 04:20:41 +0000 In-Reply-To: <20260817042048.1579415-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: <20260817042048.1579415-1-avagin@google.com> X-Mailer: git-send-email 2.55.0.691.gc56d675ccc-goog Message-ID: <20260817042048.1579415-2-avagin@google.com> Subject: [PATCH 1/8] x86/fpu: Document signal frame portability From: Andrei Vagin To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "Chang S. Bae" Cc: linux-kernel@vger.kernel.org, criu@lists.linux.dev, Dave Hansen , x86@kernel.org, Andrei Vagin , Alexander Mikhalitsyn , "H. Peter Anvin" 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 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). Reviewed-by: Alexander Mikhalitsyn Signed-off-by: Andrei Vagin --- Documentation/arch/x86/xstate.rst | 16 ++++++++++++++++ arch/x86/include/uapi/asm/sigcontext.h | 17 +++++++++++++++++ 2 files changed, 33 insertions(+) diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst index cec05ac464c1..0b4d541ab6f8 100644 --- a/Documentation/arch/x86/xstate.rst +++ b/Documentation/arch/x86/xstate.rst @@ -172,3 +172,19 @@ 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 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 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..c01f55f1fc12 100644 --- a/arch/x86/include/uapi/asm/sigcontext.h +++ b/arch/x86/include/uapi/asm/sigcontext.h @@ -34,6 +34,23 @@ * 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). + * * This extended area typically grows with newer CPUs that have larger and * larger XSAVE areas. */ -- 2.55.0.691.gc56d675ccc-goog