From patchwork Fri Dec 8 21:57:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Borislav Petkov X-Patchwork-Id: 176194 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp6122588vqy; Sat, 9 Dec 2023 08:02:46 -0800 (PST) X-Google-Smtp-Source: AGHT+IGlVAo2uaEOzbIcF+MLnxicbGxjgiIrLs8sxrf2tVpnghZpBMiGy7yafvai4ZN0Qgi2T+hr X-Received: by 2002:a05:6a00:8c0c:b0:6ce:2731:7a09 with SMTP id ih12-20020a056a008c0c00b006ce27317a09mr693581pfb.63.1702137766354; Sat, 09 Dec 2023 08:02:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702137766; cv=none; d=google.com; s=arc-20160816; b=RE3N076kp9aL813WPQiqFlgMYxhiHQE5GmWM3m8QqQPOcDnGjBdYENynblTda8Mef+ 1n1fOPNpJ7Y/J2M15PbW/rz+o+JtcHrML+zfwDDPbFxqJqeDsTK3N5oRx64YYVxFqWOV dyjSrKsUrS3IVNwiFDydv176qVA62WwljlB5fIBOUaoVHIYndVV5LiR3VTjFFRrbEGRa Mg5IhJGqiGEOGaAEuuyAjNQEVOaNzFuBX+6b620NFw1HoMAQ3xVYJ6iESpCThm3ZNoUf 2bkYkV0QB/HFYhXCodTFyofBLPqlzybdueR5g0fu+G8tt/ga2g2ynZ3xoaffyU16e3XZ Nf1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=HyxNBBw6M4t7K4FsW/QvOnMlGlVd2OH0yYe9euKlsDE=; fh=J/FDRazVTlnagEtUOTbUbcZzqL0L7+3PJxww3dz7ios=; b=CUQM0El2hU0L34avliBJ9IjdIj0bRLFCYHjViBEhVwz5lKXNyojSPRJas6Hdq5YALO +8fEkqeljBuwzYHBwuw4QsNpjTTfIT451zivDvvtxF7CE3Dmv8grK0hT1BH0oo+Pedxb NtiyPATAh9Qha/j7bHk0HgK8mjArIj0DOGunC637uRLZoDkl76FMY61M5Na2DBJqIvPJ 6/Pqei47mDW2Uao54pQPmDCS8jrqRRKieAFu/JZuqa3v79PYpnhj25fSBGpc83WL/9GS cdGbKZaacfV7YHIgSrBBkmxvv2ohA5HtA5dkBPdJuX3Xej72/0WvfxnMELPdjU8UqwgE KgXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=alien8 header.b=Me4aVv3G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id f15-20020a056a001acf00b006be30cdc3d8si3248160pfv.163.2023.12.09.08.02.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Dec 2023 08:02:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=alien8 header.b=Me4aVv3G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 3BFC0808653D; Fri, 8 Dec 2023 13:59:01 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1574830AbjLHV62 (ORCPT + 99 others); Fri, 8 Dec 2023 16:58:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236064AbjLHV6N (ORCPT ); Fri, 8 Dec 2023 16:58:13 -0500 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1E44172A for ; Fri, 8 Dec 2023 13:57:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id E02A940E00C7; Fri, 8 Dec 2023 21:57:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pu-SK4I_uqek; Fri, 8 Dec 2023 21:57:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1702072657; bh=HyxNBBw6M4t7K4FsW/QvOnMlGlVd2OH0yYe9euKlsDE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Me4aVv3Gzpsf0YqFQlL2OAjtnafSMDjF7TfgbzEUfcHH5GUjUAsCUZJXm3e80Owbr Ti3x2EGVBhawAJjaaO4qrN8mi5DYVnYSEPZRJWmlVqU3Ce//rg8D/CIpYnDdxEhIqu kLF0fZt3NQsaU4r0q8G7YNvBsmK5SH/6ZY4SwSGfySFWzbfCYgiKs17yDVG29f408r 7haQFJKorMcIRB/RQCIRMZpad4CSg9NxrkRZdwbjqYl74zkifri81a11P0NRDygOaz zLgmRupOaOlcBjU4RtUeWf7vy9bApDQZ9tg7UpBe0NOMdItSRMAAUTs4dRFxrC4XoF KaxjUp+zamt0kaYwot+VJpDFbtbamTMhig6TxS663V7e1QFQzwnlwO2B4lU1eY3PHg vI6f+V9xm8/ablZA+H+m9z4/gDYxruG+woU4RiNixTC08WrexFaY2uJgKPe1dxWp50 jN72pLsghtgniqsD+uOrttM8kOwMzScYJjhEjyXxuO/QB96RpQDx4TnTeT2q5zoX3J 1YO1tRKs8GLWPqaI3tnU1TrVpnmpHkWXI5QBn5Hn//LBBJVl89G42a0DQFTOtCqeQd Qixo+U58KxbHQbCsXHhKvchQy8Pg2z2rc+VZwFUw/kz4F4BKLFlQAuRR2mF4AyMlJc YlBxIRUl5mRI15JW/O9MYt/c= Received: from zn.tnic (pd95304da.dip0.t-ipconnect.de [217.83.4.218]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 30F8E40E00C5; Fri, 8 Dec 2023 21:57:34 +0000 (UTC) Date: Fri, 8 Dec 2023 22:57:33 +0100 From: Borislav Petkov To: Dave Hansen Cc: X86 ML , LKML Subject: [PATCH -v2] Documentation/x86: Document what /proc/cpuinfo is for Message-ID: <20231208215733.GEZXORTftWz1ubGdYl@fat_crate.local> References: <20231129101700.28482-1-bp@alien8.de> <4afd33ba-6b7c-415f-b9ef-964a2fc840d8@intel.com> <20231208215537.GDZXOQ2TKjOZJlflUz@fat_crate.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231208215537.GDZXOQ2TKjOZJlflUz@fat_crate.local> 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 groat.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 (groat.vger.email [0.0.0.0]); Fri, 08 Dec 2023 13:59:01 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783893121719634568 X-GMAIL-MSGID: 1784820810041465908 From: "Borislav Petkov (AMD)" Date: Wed, 29 Nov 2023 11:12:55 +0100 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) --- 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 08246e8ac835..8895784d4784 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? ==============================