Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
Date:   Tue, 28 Nov 2023 20:36:50 +0100
From:   Borislav Petkov <bp@alien8.de>
To:     Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/cpu: Update power flags
Message-ID: <20231128193650.GFZWZBUqhLD4AJzeO3@fat_crate.local>
References: <20231128-powerflags-v1-1-87e8fe020a3d@weissschuh.net>
 <20231128191217.GDZWY7kYC9bE9Qkg25@fat_crate.local>
 <15ea49d1-5c6e-4459-8ef1-4bca573b8b93@t-8ch.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <15ea49d1-5c6e-4459-8ef1-4bca573b8b93@t-8ch.de>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Nov 28, 2023 at 08:25:40PM +0100, Thomas Wei=C3=9Fschuh wrote:
> > The beginning of Documentation/arch/x86/cpuinfo.rst tries to explain
> > why.
>=20
> Isn't this introduction more about the cpuinfo "flags" fields?

That's why I said "tries to explain". See below - I've been meaning to
write this for a long time now.

>   power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] [15]

Yeah, nothing cares about those - see below.

Thx.

---
diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/=
cpuinfo.rst
index 08246e8ac835..95c7ebcc13a9 100644
--- a/Documentation/arch/x86/cpuinfo.rst
+++ b/Documentation/arch/x86/cpuinfo.rst
@@ -13,6 +13,29 @@ or KVM want to expose the feature to a KVM guest, it c=
an and should have
 an X86_FEATURE_* defined. These flags represent hardware features as
 well as software features.
=20
+The /proc/cpuinfo list is not exhaustive 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 even need to be in that file because
+userspace doesn't even 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 do that and the hw supports CPUID faulting, userspace can
+simply probe for the feature and figure out if it is supported or not
+
+* 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".
+
 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.


--=20
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette