From nobody Sun Feb 8 05:53:35 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1535C6FD1F for ; Wed, 22 Mar 2023 20:26:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232208AbjCVU0i (ORCPT ); Wed, 22 Mar 2023 16:26:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232172AbjCVU0S (ORCPT ); Wed, 22 Mar 2023 16:26:18 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 003A88C967; Wed, 22 Mar 2023 13:16:28 -0700 (PDT) Date: Wed, 22 Mar 2023 20:14:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1679516097; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NQQuVQiY/sIoaQ5n0A3D+PWJlpQRmQdA8vFtOkT8Gsk=; b=SLjWGkDXuJNDL12fSJydNVRbfzMtf5EXpP/AgYUjbmgIkT94WYBN8kaTVJEXxAfZMqbL4Q KY7XhbNjLJtVOxtcKO6IbPQlagTQWNSqEo/hBcbhZ3S8FpbbMRtvQy5VLqf6/zt0j39gMU t92SdepPx2ES7UzpBsX3+1UCjwKV5Ki6clPmtvKg4uUpDIR+fBDTk8xexBt8xenKULsCGg YQbIR0a/bP/TvWXW38V9HN6iQVwvrZ+7I1JnzXSBzU/2C2BrjUbp4J9CGa5o+kcXVR2gof 2XpARYNvAgEBW0iv9L2fkhLFKM1YSjElDG6idVYsmwvxCIQ5WrsHVb8LkiMcvQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1679516097; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NQQuVQiY/sIoaQ5n0A3D+PWJlpQRmQdA8vFtOkT8Gsk=; b=sLiVViCR4387AXb2Bqoab1YuTB76BZwWUIjmIk3eZIpNLJYRaXOlP1BcO0rEE6DTQVj8kj sVsJQ6jcC8qMi7DA== From: "tip-bot2 for Chang S. Bae" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/fpu] Documentation/x86: Explain the state component permission for guests Cc: "Chang S. Bae" , Dave Hansen , Thiago Macieira , Yang Zhong , Tony Luck , x86@kernel.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 Message-ID: <167951609339.5837.3788677511456464455.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/fpu branch of tip: Commit-ID: 5fbff260755750559aa12a30f6fa7f8a863666f1 Gitweb: https://git.kernel.org/tip/5fbff260755750559aa12a30f6fa7f8a8= 63666f1 Author: Chang S. Bae AuthorDate: Fri, 20 Jan 2023 16:19:00 -08:00 Committer: Dave Hansen CommitterDate: Wed, 22 Mar 2023 13:08:02 -07:00 Documentation/x86: Explain the state component permission for guests Commit 980fe2fddcff ("x86/fpu: Extend fpu_xstate_prctl() with guest permissions") extends a couple of arch_prctl(2) options for VCPU threads. Add description for them. Signed-off-by: Chang S. Bae Signed-off-by: Dave Hansen Reviewed-by: Thiago Macieira Reviewed-by: Yang Zhong Reviewed-by: Tony Luck Link: https://lore.kernel.org/all/20230121001900.14900-5-chang.seok.bae%40i= ntel.com --- Documentation/x86/xstate.rst | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/Documentation/x86/xstate.rst b/Documentation/x86/xstate.rst index 23b1c9f..ae5c69e 100644 --- a/Documentation/x86/xstate.rst +++ b/Documentation/x86/xstate.rst @@ -143,3 +143,32 @@ entry if the feature is in its initial configuration. = This differs from non-dynamic features which are always written regardless of their configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV field to determine if a features was written. + +Dynamic features for virtual machines +------------------------------------- + +The permission for the guest state component needs to be managed separately +from the host, as they are exclusive to each other. A coupled of options +are extended to control the guest permission: + +-ARCH_GET_XCOMP_GUEST_PERM + + arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features); + + ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it + provides the same semantics and functionality but for the guest + components. + +-ARCH_REQ_XCOMP_GUEST_PERM + + arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr); + + ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the + same semantics for the guest permission. While providing a similar + functionality, this comes with a constraint. Permission is frozen when the + first VCPU is created. Any attempt to change permission after that point + 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.