From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93FAD1DE4CE for ; Wed, 12 Mar 2025 19:55:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741809314; cv=none; b=E9Tf4j3IJoYgN/fm1PBaTsp/3ZQGZDnJylZy0z1FAmABFsVtlLwXQMpEMUp8U5GPh9ciLhbNzO7CLTLQeNKluoXmFH8ZTUsfayGKOb3v85gKTXWaoudbzBv/ZJmaCd7P8UzxDvva7bB+QVY61lPi7XOcCfO/tEwly+M3qDEmjqA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741809314; c=relaxed/simple; bh=CplhzlJ4smylxHe7GvjlK3HB9K0ptwoBb3gJK2jRDiY=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=g8ruCMjbf7KlVgWvoUQR/OgjdlLzLDXmc6JvNa6qM9Xrnc10oXw38pqF6ls0Vf966FaiQzsJU/TRCGagHDm3CTU7Mo+ZTaTYUuup20i5dF6YkAut4a6cG+Setou0g8rYKZUlBH8VNKtKPL5qcvqj9c5MRHVV5rxUMMhEmt/dy+k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=ND7GjzrA; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="ND7GjzrA" Received: from [127.0.0.1] ([76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 52CJsVp02657411 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 12 Mar 2025 12:54:31 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 52CJsVp02657411 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025021701; t=1741809272; bh=doQCaHhiMQgxyHB06XJnVyXGfPJ4R8+yj4l9i89I6Lg=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=ND7GjzrARImK75gOCS1BYdgH7YfLk9S8LAtRJvc/z0F1ooXAYkjFqdR+D61Jg4bwm Q015uCD2hatqoXf2PQXa4vMIUqC+We1q9rDUFe3Pm6rwp0Eo/lIIuXTkG5F1DQUwN9 gIdwKgvQtBv5vi7Muasa3wxaLkhMkBV7xMpz7ws7ZS+rEmQYZdT45WS4SVw26Xzvv0 MCzjfsYj+1zUeAontoRpQDFY1tw4VnOL+2gHQEqmAb1xHKe/cw1XjDGM/D8Nu3Z857 BqMtdQlFQzNA4xRSbST8dk1ZQJktRRjig5zUkv1CsXC1wWCEaH8/GQsqhmhf11pqU2 i+8S/efzWwvPg== Date: Wed, 12 Mar 2025 12:54:31 -0700 From: "H. Peter Anvin" To: "Ahmed S. Darwish" , Ingo Molnar , Dave Hansen , Borislav Petkov CC: Thomas Gleixner , Andrew Cooper , John Ogness , x86@kernel.org, x86-cpuid@lists.linux.dev, LKML Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_19/20=5D_tools/x86/kcpuid=3A?= =?US-ASCII?Q?_Update_bitfields_to_x86-cpuid-db_v2=2E3?= User-Agent: K-9 Mail for Android In-Reply-To: <20250312143738.458507-20-darwi@linutronix.de> References: <20250312143738.458507-1-darwi@linutronix.de> <20250312143738.458507-20-darwi@linutronix.de> Message-ID: <4BCBA481-AC3A-4A65-B791-235E580286CC@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On March 12, 2025 7:37:36 AM PDT, "Ahmed S=2E Darwish" wrote: >Update kcpuid's CSV file to version 2=2E3, as generated by x86-cpuid-db= =2E > >Summary of the v2=2E3 changes: > >* Per H=2E Peter Anvin's feedback, leaf 0x3 is not unique to Transmeta as > the CSV file earlier claimed=2E Since leaf 0x3's format differs betwee= n > Intel and Transmeta, and the project does not yet support having the > same CPUID bitfield with varying interpretations across vendors, leaf > 0x3 is removed for now=2E Given that Intel discontinued support for PS= N > from Pentium 4 onward, and Linux force disables it on early boot for > privacy concerns, this should have minimal impact=2E > >* Leaf 0x80000021: Make bitfield IDs and descriptions coherent with each > other=2E Remove "_support" from bitfield IDs, as no other leaf has suc= h > convention=2E > >Reported-by: "H=2E Peter Anvin" >Closes: https://lkml=2Ekernel=2Eorg/r/C7684E03-36E0-4D58-B6F0-78F4DB82D73= 7@zytor=2Ecom >Signed-off-by: Ahmed S=2E Darwish >Link: https://gitlab=2Ecom/x86-cpuid=2Eorg/x86-cpuid-db/-/blob/v2=2E3/CHA= NGELOG=2Erst >--- > tools/arch/x86/kcpuid/cpuid=2Ecsv | 30 +++++++++++------------------- > 1 file changed, 11 insertions(+), 19 deletions(-) > >diff --git a/tools/arch/x86/kcpuid/cpuid=2Ecsv b/tools/arch/x86/kcpuid/cp= uid=2Ecsv >index 9613e09cbfb3=2E=2E8d25b0b49f3b 100644 >--- a/tools/arch/x86/kcpuid/cpuid=2Ecsv >+++ b/tools/arch/x86/kcpuid/cpuid=2Ecsv >@@ -1,5 +1,5 @@ > # SPDX-License-Identifier: CC0-1=2E0 >-# Generator: x86-cpuid-db v2=2E2 >+# Generator: x86-cpuid-db v2=2E3 >=20 > # > # Auto-generated file=2E >@@ -116,14 +116,6 @@ > 0x2, 0, edx, 30:24, desc15 , Descri= ptor #15 > 0x2, 0, edx, 31, edx_invalid , Descri= ptors 12-15 are invalid if set >=20 >-# Leaf 3H >-# Transmeta Processor Serial Number (PSN) >- >- 0x3, 0, eax, 31:0, cpu_psn_0 , Proces= sor Serial Number bytes 0 - 3 >- 0x3, 0, ebx, 31:0, cpu_psn_1 , Proces= sor Serial Number bytes 4 - 7 >- 0x3, 0, ecx, 31:0, cpu_psn_2 , Proces= sor Serial Number bytes 8 - 11 >- 0x3, 0, edx, 31:0, cpu_psn_3 , Proces= sor Serial Number bytes 12 - 15 >- > # Leaf 4H > # Intel deterministic cache parameters >=20 >@@ -1020,20 +1012,20 @@ > 0x80000021, 0, eax, 0, no_nested_data_bp , No nes= ted data breakpoints > 0x80000021, 0, eax, 1, fsgs_non_serializing , WRMSR = to {FS,GS,KERNEL_GS}_BASE is non-serializing > 0x80000021, 0, eax, 2, lfence_rdtsc , LFENCE= always serializing / synchronizes RDTSC >-0x80000021, 0, eax, 3, smm_page_cfg_lock , SMM pa= ging configuration lock is supported >+0x80000021, 0, eax, 3, smm_page_cfg_lock , SMM pa= ging configuration lock > 0x80000021, 0, eax, 6, null_sel_clr_base , Null s= elector clears base >-0x80000021, 0, eax, 7, upper_addr_ignore , EFER M= SR Upper Address Ignore Enable bit supported >-0x80000021, 0, eax, 8, autoibrs , EFER M= SR Automatic IBRS enable bit supported >-0x80000021, 0, eax, 9, no_smm_ctl_msr , SMM_CT= L MSR (0xc0010116) is not present >-0x80000021, 0, eax, 10, fsrs_supported , Fast S= hort Rep STOSB (FSRS) is supported >-0x80000021, 0, eax, 11, fsrc_supported , Fast S= hort Rep CMPSB (FSRC) is supported >-0x80000021, 0, eax, 13, prefetch_ctl_msr , Prefet= ch control MSR is supported >+0x80000021, 0, eax, 7, upper_addr_ignore , EFER M= SR Upper Address Ignore >+0x80000021, 0, eax, 8, autoibrs , EFER M= SR Automatic IBRS >+0x80000021, 0, eax, 9, no_smm_ctl_msr , SMM_CT= L MSR (0xc0010116) is not available >+0x80000021, 0, eax, 10, fsrs , Fast S= hort Rep STOSB >+0x80000021, 0, eax, 11, fsrc , Fast S= hort Rep CMPSB >+0x80000021, 0, eax, 13, prefetch_ctl_msr , Prefet= ch control MSR is available > 0x80000021, 0, eax, 16, opcode_reclaim , Reserv= es opcode space > 0x80000021, 0, eax, 17, user_cpuid_disable , #GP wh= en executing CPUID at CPL > 0 is supported >-0x80000021, 0, eax, 18, epsf_supported , Enhanc= ed Predictive Store Forwarding (EPSF) is supported >+0x80000021, 0, eax, 18, epsf , Enhanc= ed Predictive Store Forwarding > 0x80000021, 0, eax, 22, wl_feedback , Worklo= ad-based heuristic feedback to OS >-0x80000021, 0, eax, 24, eraps_support , Enhanc= ed Return Address Predictor Security >-0x80000021, 0, eax, 27, sbpb , Suppor= t for the Selective Branch Predictor Barrier >+0x80000021, 0, eax, 24, eraps , Enhanc= ed Return Address Predictor Security >+0x80000021, 0, eax, 27, sbpb , Select= ive Branch Predictor Barrier > 0x80000021, 0, eax, 28, ibpb_brtype , Branch= predictions flushed from CPU branch predictor > 0x80000021, 0, eax, 29, srso_no , CPU is= not subject to the SRSO vulnerability > 0x80000021, 0, eax, 30, srso_uk_no , CPU is= not vulnerable to SRSO at user-kernel boundary As I said, you can simply treat leaf 3 as raw 128-bit hexadecimal number; = there really isn't a need to "interpret" it since the only meaningful use o= f it is as a unique identifier combined with vendor-FMS=2E