From patchwork Wed Nov 29 10:17:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Borislav Petkov X-Patchwork-Id: 171230 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a5a7:0:b0:403:3b70:6f57 with SMTP id d7csp239460vqn; Wed, 29 Nov 2023 02:17:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IElXAMDCURRrWZHFE7+2jJfSeQo3E7bSeFS12qeJttXjkn3udUkwf+q64XxVOavz89nVVv8 X-Received: by 2002:a05:6808:1a13:b0:3ad:ff3e:d25c with SMTP id bk19-20020a0568081a1300b003adff3ed25cmr24458865oib.53.1701253053392; Wed, 29 Nov 2023 02:17:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701253053; cv=none; d=google.com; s=arc-20160816; b=0V32mxmvGphgqqLSqOEQF1PxSWR4WwBJeHpxX6Lu/nS3mgvcgtwEPHe9eZ1+NDLZRH a8viNP4Lr2xg+9EwbQ2bPMo9nN9f62xy78KKbYPpG1riuf7HnFyEgZ9K6EkDheoHbaH7 +l8xnvjraR6SBtPqg/lYlswajlXEwO2DzZcsf3mvY1ZA1yo8K+6PfCxoO+9pH9vVkHdi S6TA2cu4iL/UZFrdXQDY7EGE5rj9cCRzgWo9t1OumUa73HQyLoFjwiwAeZT1c/VVOpWZ ML1ZGz+AoJqMPiknKsmkcLxKbjmR6gC+wrTq7agN1le54g7kVsIgzmmnNM8ynDxjVtlD 8pAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Q5g/rk/lkIRICU9/6V40lNA9wN9UVgmFei+qlurrlno=; fh=yRofEPOsMYSFYi/7/f3tXB782BWAy0107oR1j5aafGk=; b=VUUFBVV5rjtaGnaETCAdYz3WOM9d+EYI51nwcJILICECkD4rXXlMBhioVW1g937COv IXrNewhfHtHtz/YQAyHhu/bXCpu6AHBmdYoFQFkwflNuVurYUShdH0LStHsMLT2SnYlw uMkdl7blo8od0PVnoKufTghvG4B+MCrHr7qTNZ883Q+S4ShVd0D1kVwQkZu4N8+YURlv zhwvpRGKcoxgqq1aRwGkND5RRBeJ/aCkfTQPtoyoEI/6YGVJG8ZZ/92WDNxfrD/AR+vj mW/2Z6YWoBYoT/oaxrmKQXuzG2d7C7FKBS3cn+HaSvlFaEAF9siiQAj+0b1roAWHDJbw eBzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@alien8.de header.s=alien8 header.b=XkVZFO98; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id e37-20020a630f25000000b005bce8cfb592si13683447pgl.245.2023.11.29.02.17.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 02:17:33 -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=neutral (body hash did not verify) header.i=@alien8.de header.s=alien8 header.b=XkVZFO98; 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=fail (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 howler.vger.email (Postfix) with ESMTP id 0B63480966CF; Wed, 29 Nov 2023 02:17: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 S229848AbjK2KRN (ORCPT + 99 others); Wed, 29 Nov 2023 05:17:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232824AbjK2KRK (ORCPT ); Wed, 29 Nov 2023 05:17:10 -0500 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9FABD1AE for ; Wed, 29 Nov 2023 02:17:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 0993C40E019F; Wed, 29 Nov 2023 10:17:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=fail (4096-bit key) reason="fail (body has been altered)" 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 eyamEeQAGL8V; Wed, 29 Nov 2023 10:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1701253030; bh=eFpNg/8twFDseGoZdnKubcbW6QXAZq0sTnyKCpFgpmg=; h=From:To:Cc:Subject:Date:From; b=XkVZFO98xVwh9JQxSzThGl3CVW5z18BdSeSg5uF0TOx+rnKUajPg2K0hLx0nmhaH3 k+2PendEeZ9iC5mpuGxoV99zu+D22bmQAaJhwBPD5QoQ+Blz0Pv6E/mKAGXvB41U45 apEAhmJHvGHeHZt5/NbHdtqvEp3gWXQS/gd5AQmYHLe6a4nq+BCBwI3J8b68FLSQND TzMuXEmZzP8gbMJ288JXeGuhn5uyhxC6pqM/tvIfYfQAPgVfdXLq3WEeuNMoqJPkun wSW5PCWJvwwkBwWBE+Ewd+gsDU/J09hIZ5d7SuzUaZYSWjpAAe4RQNsi8JRT2q3dqA GVrqIbSFXgvMXsAqojjg74d/Hbwz1MzBzeioqGee0ygrcJEIC4BWI+7hRxMXmbhTrS cpY6iVfaO65eMc9qn5iXZIMeO5yvQqaXdVKYHnMoLoyt18GY9z/u8GvygpCqlSCTyl 6S1gFUPDzveHAQ/l00Wg0cIDhHjxGWDOGrBZjJ1ObP8106DJ8klfcFGxy3C+7MIbrC urUbjmDnc5LB+afgOA1atYn/G+Fa7Kaa6toFTOD98gC9fNuf2eiUpBLOj5OE9HYlL1 pg7OgTUDH53VrCIrWjHFYH1DCTCB8XCoBJseh8YTry7RjNXO+hlwbmuRQ0fJIgGLqO v9QT9hYAvIgo+LGgvwRvHW3o= 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 2DDEA40E0031; Wed, 29 Nov 2023 10:17:08 +0000 (UTC) From: Borislav Petkov To: X86 ML Cc: LKML Subject: [PATCH] Documentation/x86: Document what /proc/cpuinfo is for Date: Wed, 29 Nov 2023 11:17:00 +0100 Message-ID: <20231129101700.28482-1-bp@alien8.de> X-Mailer: git-send-email 2.42.0.rc0.25.ga82fb66fed25 MIME-Version: 1.0 X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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]); Wed, 29 Nov 2023 02:17:30 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783893121719634568 X-GMAIL-MSGID: 1783893121719634568 From: "Borislav Petkov (AMD)" This has been long overdue. Write down what x86's version of /proc/cpuinfo is and should be used for. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Dave Hansen --- Documentation/arch/x86/cpuinfo.rst | 79 ++++++++++++++++++++++-------- 1 file changed, 58 insertions(+), 21 deletions(-) diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst index 08246e8ac835..cede6aad27c0 100644 --- a/Documentation/arch/x86/cpuinfo.rst +++ b/Documentation/arch/x86/cpuinfo.rst @@ -7,27 +7,64 @@ 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 advertized 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 there and 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 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. + +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? ==============================