1. Patchew
  2. linux
  3. [PATCH 00/16] AMD NB and SMN rework
  4. View patch

[PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()

Yazen Ghannam posted 16 patches 1 month ago
[PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Yazen Ghannam 1 month ago 
The check for early_is_amd_nb() is only useful for systems with GART or
the NB_CFG register.

Zen-based systems (both AMD and Hygon) have neither, so return early for
them.

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
---
 arch/x86/kernel/amd_nb.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index 37b8244899d8..65884d0613f8 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -385,7 +385,6 @@ static int amd_cache_northbridges(void)
  */
 bool __init early_is_amd_nb(u32 device)
 {
-	const struct pci_device_id *misc_ids = amd_nb_misc_ids;
 	const struct pci_device_id *id;
 	u32 vendor = device & 0xffff;
 
@@ -393,11 +392,11 @@ bool __init early_is_amd_nb(u32 device)
 	    boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
 		return false;
 
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
-		misc_ids = hygon_nb_misc_ids;
+	if (boot_cpu_has(X86_FEATURE_ZEN))
+		return false;
 
 	device >>= 16;
-	for (id = misc_ids; id->vendor; id++)
+	for (id = amd_nb_misc_ids; id->vendor; id++)
 		if (vendor == id->vendor && device == id->device)
 			return true;
 	return false;
-- 
2.43.0
Re: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Borislav Petkov 1 month ago 
On Wed, Oct 23, 2024 at 05:21:37PM +0000, Yazen Ghannam wrote:
> @@ -393,11 +392,11 @@ bool __init early_is_amd_nb(u32 device)
>  	    boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
>  		return false;
>  
> -	if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> -		misc_ids = hygon_nb_misc_ids;
> +	if (boot_cpu_has(X86_FEATURE_ZEN))

check_for_deprecated_apis: WARNING: arch/x86/kernel/amd_nb.c:395: Do not use boot_cpu_has() - use cpu_feature_enabled() instead.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Yazen Ghannam 3 weeks, 6 days ago 
On Fri, Oct 25, 2024 at 05:58:30PM +0200, Borislav Petkov wrote:
> On Wed, Oct 23, 2024 at 05:21:37PM +0000, Yazen Ghannam wrote:
> > @@ -393,11 +392,11 @@ bool __init early_is_amd_nb(u32 device)
> >  	    boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
> >  		return false;
> >  
> > -	if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> > -		misc_ids = hygon_nb_misc_ids;
> > +	if (boot_cpu_has(X86_FEATURE_ZEN))
> 
> check_for_deprecated_apis: WARNING: arch/x86/kernel/amd_nb.c:395: Do not use boot_cpu_has() - use cpu_feature_enabled() instead.

Sure thing.

How can I enable this check myself?

Thanks,
Yazen
Re: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Borislav Petkov 3 weeks, 6 days ago 
On Tue, Oct 29, 2024 at 10:39:28AM -0400, Yazen Ghannam wrote:
> How can I enable this check myself?

It is part of my silly patch checking script:

https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=vp

in here:

https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/tree/.tip/bin/vp.py?h=vp

but it probably isn't ready for public consumption yet.

I probably should try to package it properly when there's time...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
RE: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Luck, Tony 3 weeks, 6 days ago 
> > > > -       if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> > > > -               misc_ids = hygon_nb_misc_ids;
> > > > +       if (boot_cpu_has(X86_FEATURE_ZEN))
> > >
> > > check_for_deprecated_apis: WARNING: arch/x86/kernel/amd_nb.c:395: Do not use boot_cpu_has() - use cpu_feature_enabled() instead.
> >
> > Sure thing.
> >
> > How can I enable this check myself?
> It is part of my silly patch checking script:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=vp
>
> in here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/tree/.tip/bin/vp.py?h=vp
>
> but it probably isn't ready for public consumption yet.
>
> I probably should try to package it properly when there's time...

Sounds like it would be a valuable addition to checkpatch.

Maybe Joe or Andy will find time before you do.

-Tony
Re: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Yazen Ghannam 3 weeks, 5 days ago 
On Tue, Oct 29, 2024 at 04:15:33PM +0000, Luck, Tony wrote:
> > > > > -       if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> > > > > -               misc_ids = hygon_nb_misc_ids;
> > > > > +       if (boot_cpu_has(X86_FEATURE_ZEN))
> > > >
> > > > check_for_deprecated_apis: WARNING: arch/x86/kernel/amd_nb.c:395: Do not use boot_cpu_has() - use cpu_feature_enabled() instead.
> > >
> > > Sure thing.
> > >
> > > How can I enable this check myself?
> > It is part of my silly patch checking script:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=vp
> >
> > in here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/tree/.tip/bin/vp.py?h=vp
> >
> > but it probably isn't ready for public consumption yet.
> >
> > I probably should try to package it properly when there's time...
> 
> Sounds like it would be a valuable addition to checkpatch.
> 
> Maybe Joe or Andy will find time before you do.
>

And if not to checkpatch, then maybe it can be included in the TIP
maintainers' handbook? That is, if others are using it or something
similar.

Thanks,
Yazen
Re: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Borislav Petkov 3 weeks, 4 days ago 
On Wed, Oct 30, 2024 at 10:21:38AM -0400, Yazen Ghannam wrote:
> And if not to checkpatch, then maybe it can be included in the TIP
> maintainers' handbook? That is, if others are using it or something
> similar.

Nah, this needs to be a normal janitor task. tglx is working on it. :)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 03/16] x86/amd_nb: Clean up early_is_amd_nb()
Posted by Sohil Mehta 3 weeks, 4 days ago 
> On Tue, Oct 29, 2024 at 04:15:33PM +0000, Luck, Tony wrote:
>>>>>> -       if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
>>>>>> -               misc_ids = hygon_nb_misc_ids;
>>>>>> +       if (boot_cpu_has(X86_FEATURE_ZEN))
>>>>>
>>>>> check_for_deprecated_apis: WARNING: arch/x86/kernel/amd_nb.c:395: Do not use boot_cpu_has() - use cpu_feature_enabled() instead.
>>>>


Do the comments in cpufeature.h need updating? It seems to recommend
boot_cpu_has() in most cases and suggests using static_cpu_has() (which
is used by cpu_feature_enabled()) only in fast paths.


/*
 * Static testing of CPU features. Used the same as boot_cpu_has(). It
 * statically patches the target code for additional performance. Use
 * static_cpu_has() only in fast paths, where every cycle counts. Which
 * means that the boot_cpu_has() variant is already fast enough for the
 * majority of cases and you should stick to using it as it is generally
 * only two instructions: a RIP-relative MOV and a TEST.
 *
 ...

 */
static __always_inline bool _static_cpu_has(u16 bit)


> 
> And if not to checkpatch, then maybe it can be included in the TIP
> maintainers' handbook? That is, if others are using it or something
> similar.
>
[PATCH] x86/cpufeature: Document cpu_feature_enabled() as the default to use
Posted by Borislav Petkov 3 weeks, 4 days ago 
From: "Borislav Petkov (AMD)" <bp@alien8.de>

cpu_feature_enabled() should be used in most cases when CPU feature
support needs to be tested in code. Document that.

Reported-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
---
 arch/x86/include/asm/cpufeature.h | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 0b9611da6c53..de1ad09fe8d7 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -132,11 +132,12 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 	 x86_this_cpu_test_bit(bit, cpu_info.x86_capability))
 
 /*
- * This macro is for detection of features which need kernel
- * infrastructure to be used.  It may *not* directly test the CPU
- * itself.  Use the cpu_has() family if you want true runtime
- * testing of CPU features, like in hypervisor code where you are
- * supporting a possible guest feature where host support for it
+ * This is the default CPU features testing macro to use in code.
+ *
+ * It is for detection of features which need kernel infrastructure to be
+ * used.  It may *not* directly test the CPU itself.  Use the cpu_has() family
+ * if you want true runtime testing of CPU features, like in hypervisor code
+ * where you are supporting a possible guest feature where host support for it
  * is not relevant.
  */
 #define cpu_feature_enabled(bit)	\
@@ -161,13 +162,6 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
 #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
 
 /*
- * Static testing of CPU features. Used the same as boot_cpu_has(). It
- * statically patches the target code for additional performance. Use
- * static_cpu_has() only in fast paths, where every cycle counts. Which
- * means that the boot_cpu_has() variant is already fast enough for the
- * majority of cases and you should stick to using it as it is generally
- * only two instructions: a RIP-relative MOV and a TEST.
- *
  * Do not use an "m" constraint for [cap_byte] here: gcc doesn't know
  * that this is only used on a fallback path and will sometimes cause
  * it to manifest the address of boot_cpu_data in a register, fouling
-- 
2.43.0

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] x86/cpufeature: Document cpu_feature_enabled() as the default to use
Posted by Dave Hansen 2 weeks, 6 days ago 
On 10/31/24 03:34, Borislav Petkov wrote:
> cpu_feature_enabled() should be used in most cases when CPU feature
> support needs to be tested in code. Document that.

Yes, please.  BTW, I know the code generation isn't great in some cases.
 But this is the right _way_ to call things no "boot_" or &boot_cpu_data
for system-wide things.  Underlying code generation can continue to be
fixed up over time.

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Re: [PATCH] x86/cpufeature: Document cpu_feature_enabled() as the default to use
Posted by Sohil Mehta 3 weeks, 4 days ago 
On 10/31/2024 3:34 AM, Borislav Petkov wrote:
> From: "Borislav Petkov (AMD)" <bp@alien8.de>
> 
> cpu_feature_enabled() should be used in most cases when CPU feature
> support needs to be tested in code. Document that.
> 
> Reported-by: Sohil Mehta <sohil.mehta@intel.com>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> ---
>  arch/x86/include/asm/cpufeature.h | 18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 

Looks good (a minor nit below),
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>


> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index 0b9611da6c53..de1ad09fe8d7 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -132,11 +132,12 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
>  	 x86_this_cpu_test_bit(bit, cpu_info.x86_capability))
>  
>  /*
> - * This macro is for detection of features which need kernel
> - * infrastructure to be used.  It may *not* directly test the CPU
> - * itself.  Use the cpu_has() family if you want true runtime
> - * testing of CPU features, like in hypervisor code where you are
> - * supporting a possible guest feature where host support for it
> + * This is the default CPU features testing macro to use in code.
> + *

Does "default CPU feature testing macro" roll better than "default CPU
features testing macro"?

> + * It is for detection of features which need kernel infrastructure to be
> + * used.  It may *not* directly test the CPU itself.  Use the cpu_has() family
> + * if you want true runtime testing of CPU features, like in hypervisor code
> + * where you are supporting a possible guest feature where host support for it
>   * is not relevant.
>   */
Re: [PATCH] x86/cpufeature: Document cpu_feature_enabled() as the default to use
Posted by Borislav Petkov 3 weeks, 4 days ago 
On October 31, 2024 7:26:27 PM GMT+01:00, Sohil Mehta <sohil.mehta@intel.com> wrote:
>Does "default CPU feature testing macro" roll better than "default CPU
>features testing macro"?

Waaay too finicky to me. No one cares, I'd say. 🤗😂

-- 
Sent from a small device: formatting sucks and brevity is inevitable.

Patchew 2.1-devel-b67e4c2

© 2016 - 2024 Red Hat, Inc.