linux-kernel - Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2d1cd1a3-4447-41e7-9af8-6cf80876247d@intel.com>
Date: Tue, 10 Feb 2026 14:13:10 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>
CC: <zhao1.liu@...el.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"
	<hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Jon Kohler
	<jon@...anix.com>, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, "Peter
 Zijlstra (Intel)" <peterz@...radead.org>, Thomas Gleixner <tglx@...nel.org>,
	Tony Luck <tony.luck@...el.com>, <x86@...nel.org>, Iwona Winiarska
	<iwona.winiarska@...el.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into
 separate header

On 2/6/2026 3:14 PM, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> The intel-family.h header uses Vendor/Family/Model macros but it does not
> #include the header where they are defined. If that header is included,
> the build blows up in #include hell.
> 

Is the cause of the #include hell the single line in peci-cpu.h?

	#include "../../arch/x86/include/asm/intel-family.h"

intel-family.h also uses the X86_VENDOR_INTEL from asm/processor.h
without including that header.

At some point would we want to fix that as well? However, that would
contradict the comment you add in patch 2, "Do not use any x86-specific
headers.." in intel-family.h. Any solution for this would also run into
the same issues.

Therefore, the PECI driver currently does:

	/* Copied from x86 <asm/processor.h> */
	#define X86_VENDOR_INTEL       0
	/* End of copied code */

So, anytime intel-family.h needs to use something x86 specific, the PECI
driver needs to either copy it or we would need to move it to generic code.

> Luckily, these macros are completely independent and do not themselves
> have any dependencies on other code.
> 
> Break the VFM_*() macros out into their own header.
> 
> Note that the new header is in asm-generic. Believe it or not, the
> intel-family.h header is included from a driver in arch-generic code:
> 
> 	#include "../../arch/x86/include/asm/intel-family.h"
> 
> Putting the header in generic code will move in the right direction
> of reducing the amount of code that the "peci" driver needs to copy.
> 

AFAIU, the PECI driver is the only user of this VFM stuff in non-x86
code. Are we expecting other generic usages for it?

The VFM macros and the VFM model defines usually go hand-in-hand. Is
there a reason for keeping intel-family header in arch/x86 but the VFM
one in asm-generic/?

I wonder if it would more consistent to move the VFM macros into
arch/x86/include/asm/vfm.h?

And then let the PECI driver do:

	#include "../../arch/x86/include/asm/vfm.h"

Though, intel-family.h would probably need:

	#ifdef CONFIG_X86
	#include <asm/vfm.h>
	#endif

This isn't ideal but at least the ugliness is limited to a few lines in
one specific driver. This avoids the need to add x86-specific includes
to the otherwise tidy asm-generic folder.

However, this wouldn't solve the X86_VENDOR_INTEL issue or any future
dependencies in intel-family.h.

Maybe it is time to revisit the reasoning that led to the current PECI
driver implementation :)
https://lore.kernel.org/lkml/67f2cfda-c78b-6282-f5a3-2f345f8e2849@intel.com/