Re: [PATCH v4 4/5] x86/amd_node: Skip SMN setup on Hygon Fam18h models 0x04-0x08

[Yazen Ghannam <yazen.ghannam@amd.com>]

On Thu, Sep 03, 2026 at 09:49:58AM +0800, Lin Wang wrote:
> 
> 
> On 9/2/2026 11:13 PM, Borislav Petkov wrote:
> > On Wed, Sep 02, 2026 at 02:22:13PM +0800, Lin Wang wrote:
> > > Please let me know how you would prefer this to be handled.
> > 
> > Well, X86_FEATURE_ZEN isn't Hygon apparently. Otherwise, we wouldn't be having
> > this conversation. And we wouldn't need ugly workarounds like that.
> > 
> > Which means, you cannot set it on Hygon. Instead, you should check vendor or
> > define your own X86_FEATURE_HYGON if you think it would be useful to denote
> > common set of features between all Hygon cores.
> > 
> > Reusing an AMD-specific flag but then having different hardware which needs
> > hacks and workarounds to the code is not what you do. Hygon is a different
> > vendor and it should be treated as such - not piggyback on AMD code.
> > 
> > Unless you wanna piggyback. But then you have to extract it properly and make
> > it generic so that it can be shared. I have been asking all people submitting
> > Hygon code to do that and you are starting to do it but then you need to stick
> > to it and do only that.
> > 
> 
> Hi Boris,
> 
> Thanks for clarifying the direction.
> 
> My proposed approach is to use explicit vendor checks to make
> init_amd_nbs() and amd_smn_init() AMD-only. Hygon node enumeration and
> SMN setup would remain in Hygon code.
> 
> Sashiko's concern with v3 was that the AMD initializers were restricted
> while Hygon call sites remained. However, as currently implemented, the
> AMD NB and SMN paths are based on AMD topology assumptions and cannot
> provide the Hygon node and SMN mappings.
> 

The "vendor != HYGON" restriction would be fair.

I don't understand how the "model-specific" restriction is better.
Wouldn't it cause similar problems?

> I would first stop the affected Hygon call sites from entering those AMD
> paths, and then make the two initializers AMD-only in the same series.
> Later driver support would use the Hygon interfaces.
> 
> Would this ordering address the Sashiko concern?
> 

Right, so first you provide a Hygon-only option for all affected call
sites. Then you add the vendor check. This ensures that the affected
callers don't break in the middle of the patch series.

Is this your intent?

Regarding the Zen feature flag, I think it may be overloaded.

Hygon systems are Zen systems. The same Zen1 architecture was used
orginally, though I don't know how much things have diverged since then.

All Hygon systems are Zen systems, but not all AMD systems are Zen
systems.

So we have three diverging Platforms:
1) AMD legacy (Northbridge / !Zen)
2) AMD modern (Zen)
3) Hygon (Zen by default)

(2) and (3) where the same until recently.

Maybe we define new feature flags that indicate a Platform/Interconnect
group? That way we won't need to rely on PCI IDs or vendor+core
combinations.

FYI, that was the intent to use the Zen feature flag here. It was a way
to distinguish (1) and (2/3) above. It worked until it didn't. :)

Thanks,
Yazen