From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f201.google.com (mail-oi1-f201.google.com [209.85.167.201]) (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 E8C5A3AEF4C for ; Mon, 15 Jun 2026 19:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781552246; cv=none; b=MeA5TS8AM8bb5G9MGvtF//K+C87tq212grcSm7TcPo3MoNuzz/p7nD3MLOibV0h/vxIzq0gFt7X3R2ZEc3S4veOwLiVLDPMepqdAaT5q5iTvN2JCZiR0nxnjMmohOQ+8W8MKNXZ4Se/FOr6yD/QvCqES7io+B9TGa/jFOuuIUlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781552246; c=relaxed/simple; bh=GATAbFM5bc+/2pU3aaR44YPFgNPsTAtp56hf372cirE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YgagsNPZ+sU4wxRn6VzuMA8yht5EmWnu2I9h9ftGAaMiEvaYHfhFQ10XewHoncgrUtP2PchXgkH5ta26it3gGR0MG4QLMpYCg+NebzM5+SMKiUjcTvk2R5EIqfZs2Iiwa4UW4qdv8aqO8O9GNJC7gqEuEHXz70YxT5uTIALAeRQ= 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=qvRsVcqc; arc=none smtp.client-ip=209.85.167.201 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="qvRsVcqc" Received: by mail-oi1-f201.google.com with SMTP id 5614622812f47-48576b309c7so6044864b6e.3 for ; Mon, 15 Jun 2026 12:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781552244; x=1782157044; 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=MzrWl3jZB9JQWvUiqGPCXH0DTxZYSfaBSOYpTUfasuU=; b=qvRsVcqcQGIdtFVr6NLh45zsm26xifiVy+hL2bTUY+9xsIq9OiEf1B+3mpp3bmON68 y3u+aCqzSOVvMbC5o5f53HVGvzDJyFXDHqJJdAv3xIZe/pRb0wLeeazWbq+72So9cJRY nTVFQaFw9ycv90VyL/4WNS3y2J4koQ/IPcReDSpbTXsKJ1XCh7vNXkW6SDY8h/tO0unn f87JZF89w6wPRrVUPQDNQaplfS+SFs1IihKgwa4S4dcT4QCiTDfLfoGyDXzv0rgs0Hmr Y9NJHGzaLUPCNNGKsP043XDI5d7F8lAn+kH4vK/lD0FH74qmq5+BVjWO+ia/ULz88zKT rLGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781552244; x=1782157044; 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=MzrWl3jZB9JQWvUiqGPCXH0DTxZYSfaBSOYpTUfasuU=; b=DZVybZXEIzoEz82Zo+Qg7WnASFi1NmAIqe76PoVGoDhd36cH6LO3t4IZklykuL6pyh fxk6HtKUXFlcIrprqzTniVdWhlm4gMPDKQs3KH4aqbg7C+/ZQKDHjg+6nHyxc9ElIXmc rppl8PrDq71ICvDCf7NssjgYWy6aE1IL9o8+BWteHPNEzmH3XXJHVxH2f7MQDPyf9FIJ hhs7srzXJ5NPgr/3nxRHk7cBMSIlzgVWPfAcJof7YCq6isK2XpmCGqpdcqSQRCBKZZNS HQ86y62K2EEpAQ3bFobX9N2qYWK9HxJfY7dsReywoCgI3Qol+vHEMCdoH7WAq93MeMvJ pe7g== X-Gm-Message-State: AOJu0YyAczQpi/AjFNHTFPxg4+09mMdykmPilZ27r1Shf0IBsrwOHWFd opXiwT4/Fi8fzvGDgXYnLrLAHqhQX5tgxzFC3TW3nd4bjlNuGzGVpMGlH16+VWa5ANWqpG+9pYl 8bUo7lw== X-Received: from iosk20.prod.google.com ([2002:a5d:97d4:0:b0:96a:6cf8:4cc2]) (user=avagin job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6808:1999:b0:467:58e:5d73 with SMTP id 5614622812f47-4884c059035mr406906b6e.19.1781552243544; Mon, 15 Jun 2026 12:37:23 -0700 (PDT) Date: Mon, 15 Jun 2026 19:37:07 +0000 In-Reply-To: <20260615193716.1843340-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: <20260615193716.1843340-1-avagin@google.com> X-Mailer: git-send-email 2.54.0.1189.g8c84645362-goog Message-ID: <20260615193716.1843340-2-avagin@google.com> Subject: [PATCH 01/10] 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 , "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 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 | 13 +++++++++++++ arch/x86/include/uapi/asm/sigcontext.h | 13 +++++++++++++ 2 files changed, 26 insertions(+) diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst index cec05ac464c1..facd97b26bf1 100644 --- a/Documentation/arch/x86/xstate.rst +++ b/Documentation/arch/x86/xstate.rst @@ -172,3 +172,16 @@ 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 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..d52313345f21 100644 --- a/arch/x86/include/uapi/asm/sigcontext.h +++ b/arch/x86/include/uapi/asm/sigcontext.h @@ -34,6 +34,19 @@ * 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 fxregs_state and xstate_header). This size is used in + * conjunction with the pointer to the xstate context to locate + * FP_XSTATE_MAGIC2. Note that on 32-bit systems, the fpstate pointer points + * to a legacy struct fregs_state (112 bytes) 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 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.1189.g8c84645362-goog