Re: [PATCH PATCH 9/9] x86/rfds: Exclude P-only parts from the RFDS affected list

[Pawan Gupta]

On Mon, Jun 17, 2024 at 07:33:13AM -0700, Dave Hansen wrote:
> On 6/17/24 02:12, Pawan Gupta wrote:
> > +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues)	\
> > +	X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues)
> > +
> ...
> >  	/* Match more than Vendor/Family/Model */
> >  	VULNBL_INTEL_STEPPINGS(COMETLAKE_L,	X86_STEPPINGS(0x0, 0x0),	MMIO | RETBLEED),
> >  	VULNBL_INTEL	      (COMETLAKE_L,					MMIO | MMIO_SBDS | RETBLEED | GDS),
> > +	VULNBL_INTEL_CPU_TYPE (RAPTORLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> > +	VULNBL_INTEL_CPU_TYPE (ALDERLAKE,	X86_CPU_TYPE_INTEL_ATOM,	RFDS),
> 
> Could we tweak this a bit to make it more compact?  For instance, if we
> did this:
> 
> #define VULNBL_INTEL_TYPE(vfm, cpu_type, issues)	\
> 		X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm,	\
> 		X86_CPU_TYPE_INTEL_##cpu_type,		\	
> 		issues)
> 
> We'd end up with entries like this:
> 
> 	VULNBL_INTEL_TYPE (ALDERLAKE,	ATOM,	RFDS),
> 
> I guess "TYPE" is a _bit_ ambiguous.  But it's also pretty patently
> obvious what's going on versus something like this:
> 
> 	VULNBL_INTEL	  (COMETLAKE_L,	MMIO | MMIO_SBDS | RETBLEED...),
> 
> Getting rid of the "X86_CPU_TYPE_INTEL_" string in the table is low
> hanging fruit.  I don't feel as strongly about changing the new macro name.

It makes sense to me, atleast getting rid of X86_CPU_TYPE_INTEL_ in
X86_CPU_TYPE_INTEL_ATOM.