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 EA3EF261586 for ; Fri, 13 Feb 2026 20:25:48 +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=1771014350; cv=none; b=Yre+Tl8DfrAqk/G5RMwvwfPWJ94tVVrg2Wz3iamTkfnhwbse/0cgMu7fKQpZzxk6RM8G9suMogD82f0mNh1Hv5RLMj4VpsiKLtWlK1iVwwxI/Kci6Sg34CgwgjdGKtQI1ow3kBKG1mpt7PnoXilBiXXkYt0tFSTkNNNH9Umhu2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771014350; c=relaxed/simple; bh=9V6CB9zEke0VPHbQcYkVX9iOL16gBqdfDTn0RdLsEGY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=abvtpf3m/+NoEkKSUXMhVsUZ0KNtelv+k5y1JEJjJv95uO+m11Rbc+lSZjCeUte0TS/3Lbok9htygfwXMZBxPIGyUVEDaFj0PCxNE8vBzHOLQSupzvYSi7JSqq+3yLMtX0wAo1Yvm3yISzjIym7z3k/tB34xH/PyU8tEC/yocaQ= 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=215x+gI6; 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="215x+gI6" Received: from [IPV6:2607:fb90:3709:ce04:bf4c:86df:148a:f3f5] ([IPv6:2607:fb90:3709:ce04:bf4c:86df:148a:f3f5]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 61DKNwNj953157 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 13 Feb 2026 12:24:52 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 61DKNwNj953157 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026012301; t=1771014297; bh=U05UyVt7OwKCCap7JUa9o/V1bg5CnXFilRiQi1Ln1m0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=215x+gI6GViPtI64jH4PVL/VY3aiFzFjXpO8gvrtN6IlAONFLKzJYQ/0wFWg8busl I1lC4TCameqnUl2c1chEgygzSq+9qU99TXUa4PZJqK4p1aPy+96a4/i+KB2BkuLxem zhM+2HTgqzxq0pSpUby15coqHUzAYT0SoyW4uSn1kmqXldJRGH0t3CaqkXirUtmBko mKwdWHx7OG74/KHG59+KnkP5A3pdjvic31VX/t5zuVvtU/Ws071dGEEFuZOahwT6CP z98Vtv/Ze/D5ecC2cieVDuIGVMdy+f955pE4rkPlsSSYC7fN7UyzVSgH4MA2XnVJ1k mZatinF3ACYOg== Message-ID: Date: Fri, 13 Feb 2026 12:23:44 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 0/3] x86: Capability bits fix and required bits sanity check To: Maciej Wieczor-Retman , brgerst@gmail.com, bp@alien8.de, ebiggers@google.com, jackmanb@google.com, peterz@infradead.org, pawan.kumar.gupta@linux.intel.com, maciej.wieczor-retman@intel.com, mingo@redhat.com, dave.hansen@linux.intel.com, babu.moger@amd.com, sohil.mehta@intel.com, elena.reshetova@intel.com, ubizjak@gmail.com, chang.seok.bae@intel.com, darwi@linutronix.de, ak@linux.intel.com, tglx@kernel.org, nik.borisov@suse.com, xin@zytor.com Cc: linux-kernel@vger.kernel.org, x86@kernel.org, pawel.chmielewski@linux.intel.com References: Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-02-12 07:33, Maciej Wieczor-Retman wrote: > Series aims to fix the inconsistency between the cpuinfo behavior and > the documentation. Specifically the features that are not compiled are > still present in the cpuinfo bitmasks as enabled. This is not in line > with the documentation which specifies that not-compiled features are > not present in /proc/cpuinfo. > > Along adding the disabled feature bitmask initializer array, the > complementary required bitmask initializer is also added. It can be used > to provide a sanity check, after the cpu identification is finished, to > make sure every required bit is set in the final bitmask. A warning with > the cpu number and all required bits that were not set is emitted in > case of the sanity check failure. > > Before adding the sanity check a small cleanup can be done. Three places > open code an operation that retrieves either a feature string or, if the > string is not present, the feature number in word:bit format. One of > these places also doesn't check whether the string is actually there or > not. The cleanup patch fixes that and simplifies the other two > instances. I am explicitly NOT suggesting this for this patchset, but in the future, I would also like to see even the CPUID flags NOT included in /proc/cpuinfo to be in the table, for the purpose of displaying kernel messages. I fully agree that including them in /proc/cpuinfo is an unnecessary burden, but it would still be good to be able to print them in messages in cleartext, *especially* for when bits get reassigned or recycled. I would also like to see the module ID strings for CPU features change from using the numeric representation to the string representation for the same reasons. However, let me also say this: I don't think it makes any sense whatsoever to aggressively compact those CPUID leaves that are likely to grow more bits in the future (which aren't everyone, of course). It isn't like these words are particularly expensive. -hpa