From patchwork Sat Dec 9 08:21:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tip-bot2 for Thomas Gleixner X-Patchwork-Id: 176147 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5939360vqy; Sat, 9 Dec 2023 00:21:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IGuPTbO+jbHsJ8puEjk0xhISoYeyvZh9SZ6bRUE1fmZ//8O2UhdOXF8AjGXJAwnNSU4ojJC X-Received: by 2002:a05:6e02:1d8e:b0:35d:73b2:f588 with SMTP id h14-20020a056e021d8e00b0035d73b2f588mr1821217ila.12.1702110096110; Sat, 09 Dec 2023 00:21:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702110096; cv=none; d=google.com; s=arc-20160816; b=OPjFvvXkBhx0tephesOlqT2JIMoG7n1ltPEvnQiZYo+m6JkrrCLgnEt5sk0OG3MIA0 rELOIbjN0sj8a6EDr5Wgq/r8boHAfxPb5OLkl/9d9PDchSHzq9pUybch1fugyxhdPE8x oTW8/uosGAGnrMVGw5WyO1Ux65ByfWDLxsOBy5TXYWBFWLUZbYmjLAiHChvobsnGpNK6 nphotyJPWrMlDWHnGQBb3v4sF1QQZ3jQi1kMi61n4M7PkkrNPlAI1iToEPgYAbPCDr8X bU0xUQ8opAqVuJ+Y5hv3WayHz44Slg/+0d4S1y+MX/n8uDX38R2FnoDpPO3PzE/6lJCz cnZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=FWz7AeYIHKHqsW/mXloUGmsrK7/eiI9uEX3App/Fv4g=; fh=kV1u4CTNdrShQFqF0avnFGijruJJdcaHHc3ziBbw+UM=; b=lr9WPMAEkIctl7PSclMtDxohx4AQuN2oIiGaEHtGa6zgCJOtJPXshWFXh8oppUGmU8 j9j4DFmQ4Ehb3CCIZTx/vVon7IjvvUT6GmxaHwStVMqKo1JV0298ohv4mNExF1iZzJkn 9OO+Q+HSTfDk9OTcaXFx8JQMQlhcxY7gc5psprkPtvdehbqFFXRUuL1HN/bkaSPScLFO QAw8TDL+9K820Pm0fkTxA4hmFrbipiDRdUBcodO7Xe91khlJt4IlhBaWN5EYGzux2i4X AGeXCShvLfax6TAVY4VLu70CUdDjRnGRIwhWM+dBkka139xqug6lhapbEiSU/b1HJaMQ JXGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=40QoeA05; dkim=neutral (no key) header.i=@linutronix.de header.b=NnGS9SIn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id jj22-20020a170903049600b001d0b0334bd3si2826948plb.375.2023.12.09.00.21.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Dec 2023 00:21:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=40QoeA05; dkim=neutral (no key) header.i=@linutronix.de header.b=NnGS9SIn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 2BEE381168B8; Sat, 9 Dec 2023 00:21:30 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234535AbjLIIVU (ORCPT + 99 others); Sat, 9 Dec 2023 03:21:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjLIIVS (ORCPT ); Sat, 9 Dec 2023 03:21:18 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8503C122; Sat, 9 Dec 2023 00:21:23 -0800 (PST) Date: Sat, 09 Dec 2023 08:21:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1702110081; 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: in-reply-to:in-reply-to:references:references; bh=FWz7AeYIHKHqsW/mXloUGmsrK7/eiI9uEX3App/Fv4g=; b=40QoeA05rg4QTQYMRvO8as1Pnj3+EZkr6BLVMKSgXVFUI5FsgGh2Hrg2/PChHJi6d4TvkT 1x2FfcTGIjiRtCvYHj7HGgjzh0lzG0ZVVRyvNaw880cyFy8aGZZDt5u8dluSeWVisvXCm0 ZTXHsNHNNurT21okWFhFwDxrR5jeqY0Wsq+Q5EbXsFWGK0uEDlHXpG59c1VnKrVvlfBj/S r1sUDVwpOcbyWU+lNAPo9Sx2SJnKGbkdb13BkgqMTJTYz+THysIngMz4aOQcQ66AZ71FDg 3tSey8OTrgptMbugqpnhf4xXHNXR0rHYEDc/BgrLTb/ciOo2NMYqmI3PtpVTMw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1702110081; 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: in-reply-to:in-reply-to:references:references; bh=FWz7AeYIHKHqsW/mXloUGmsrK7/eiI9uEX3App/Fv4g=; b=NnGS9SIneIZ06pnHEBieqm0l+DqqyqlXchbE5bFNCjUR7jEITXNZ7R3OpClH9qlZVGMkew X+BycAh6oi3kz6AA== From: "tip-bot2 for Borislav Petkov (AMD)" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/misc] Documentation/x86: Document what /proc/cpuinfo is for Cc: "Borislav Petkov (AMD)" , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231129101700.28482-1-bp@alien8.de> References: <20231129101700.28482-1-bp@alien8.de> MIME-Version: 1.0 Message-ID: <170211008011.398.14299580912908619264.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Sat, 09 Dec 2023 00:21:30 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783893121719634568 X-GMAIL-MSGID: 1784791796106303523 The following commit has been merged into the x86/misc branch of tip: Commit-ID: 79c603ee43b2674fba0257803bab265147821955 Gitweb: https://git.kernel.org/tip/79c603ee43b2674fba0257803bab265147821955 Author: Borislav Petkov (AMD) AuthorDate: Fri, 08 Dec 2023 22:57:33 +01:00 Committer: Borislav Petkov (AMD) CommitterDate: Sat, 09 Dec 2023 08:52:53 +01:00 Documentation/x86: Document what /proc/cpuinfo is for This has been long overdue. Write down what x86's version of /proc/cpuinfo is and should be used for. With improvements by dhansen. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Dave Hansen Link: https://lore.kernel.org/r/20231129101700.28482-1-bp@alien8.de --- Documentation/arch/x86/cpuinfo.rst | 89 ++++++++++++++++++++++------- 1 file changed, 68 insertions(+), 21 deletions(-) diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst index 08246e8..8895784 100644 --- a/Documentation/arch/x86/cpuinfo.rst +++ b/Documentation/arch/x86/cpuinfo.rst @@ -7,27 +7,74 @@ x86 Feature Flags Introduction ============ -On x86, flags appearing in /proc/cpuinfo have an X86_FEATURE definition -in arch/x86/include/asm/cpufeatures.h. If the kernel cares about a feature -or KVM want to expose the feature to a KVM guest, it can and should have -an X86_FEATURE_* defined. These flags represent hardware features as -well as software features. - -If users want to know if a feature is available on a given system, they -try to find the flag in /proc/cpuinfo. If a given flag is present, it -means that the kernel supports it and is currently making it available. -If such flag represents a hardware feature, it also means that the -hardware supports it. - -If the expected flag does not appear in /proc/cpuinfo, things are murkier. -Users need to find out the reason why the flag is missing and find the way -how to enable it, which is not always easy. There are several factors that -can explain missing flags: the expected feature failed to enable, the feature -is missing in hardware, platform firmware did not enable it, the feature is -disabled at build or run time, an old kernel is in use, or the kernel does -not support the feature and thus has not enabled it. In general, /proc/cpuinfo -shows features which the kernel supports. For a full list of CPUID flags -which the CPU supports, use tools/arch/x86/kcpuid. +The list of feature flags in /proc/cpuinfo is not complete and +represents an ill-fated attempt from long time ago to put feature flags +in an easy to find place for userspace. + +However, the amount of feature flags is growing by the CPU generation, +leading to unparseable and unwieldy /proc/cpuinfo. + +What is more, those feature flags do not even need to be in that file +because userspace doesn't care about them - glibc et al already use +CPUID to find out what the target machine supports and what not. + +And even if it doesn't show a particular feature flag - although the CPU +still does have support for the respective hardware functionality and +said CPU supports CPUID faulting - userspace can simply probe for the +feature and figure out if it is supported or not, regardless of whether +it is being advertised somewhere. + +Furthermore, those flag strings become an ABI the moment they appear +there and maintaining them forever when nothing even uses them is a lot +of wasted effort. + +So, the current use of /proc/cpuinfo is to show features which the +kernel has *enabled* and *supports*. As in: the CPUID feature flag is +there, there's an additional setup which the kernel has done while +booting and the functionality is ready to use. A perfect example for +that is "user_shstk" where additional code enablement is present in the +kernel to support shadow stack for user programs. + +So, if users want to know if a feature is available on a given system, +they try to find the flag in /proc/cpuinfo. If a given flag is present, +it means that + +* the kernel knows about the feature enough to have an X86_FEATURE bit + +* the kernel supports it and is currently making it available either to + userspace or some other part of the kernel + +* if the flag represents a hardware feature the hardware supports it. + +The absence of a flag in /proc/cpuinfo by itself means almost nothing to +an end user. + +On the one hand, a feature like "vaes" might be fully available to user +applications on a kernel that has not defined X86_FEATURE_VAES and thus +there is no "vaes" in /proc/cpuinfo. + +On the other hand, a new kernel running on non-VAES hardware would also +have no "vaes" in /proc/cpuinfo. There's no way for an application or +user to tell the difference. + +The end result is that the flags field in /proc/cpuinfo is marginally +useful for kernel debugging, but not really for anything else. +Applications should instead use things like the glibc facilities for +querying CPU support. Users should rely on tools like +tools/arch/x86/kcpuid and cpuid(1). + +Regarding implementation, flags appearing in /proc/cpuinfo have an +X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h. These flags +represent hardware features as well as software features. + +If the kernel cares about a feature or KVM want to expose the feature to +a KVM guest, it should only then expose it to the guest when the guest +needs to parse /proc/cpuinfo. Which, as mentioned above, is highly +unlikely. KVM can synthesize the CPUID bit and the KVM guest can simply +query CPUID and figure out what the hypervisor supports and what not. As +already stated, /proc/cpuinfo is not a dumping ground for useless +feature flags. + How are feature flags created? ==============================