From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
tony.luck@intel.com, x86@kernel.org,
Smita.KoralahalliChannabasappa@amd.com
Subject: Re: [PATCH v2 1/8] x86/CPU/AMD: Save NodeId on AMD-based systems
Date: Wed, 16 Sep 2020 14:51:52 -0500 [thread overview]
Message-ID: <20200916195152.GA3042858@yaz-nikka.amd.com> (raw)
In-Reply-To: <20200915083259.GC14436@zn.tnic>
On Tue, Sep 15, 2020 at 10:35:15AM +0200, Borislav Petkov wrote:
...
> > Yeah, I think example 4b works here. The mismatch though is with
> > phys_proc_id and package on AMD systems. You can see above that
> > phys_proc_id gives a socket number, and the AMD NodeId gives a package
> > number.
>
> Ok, now looka here:
>
> " - cpuinfo_x86.logical_proc_id:
>
> The logical ID of the package. As we do not trust BIOSes to enumerate the
> packages in a consistent way, we introduced the concept of logical package
> ID so we can sanely calculate the number of maximum possible packages in
> the system and have the packages enumerated linearly."
>
> Doesn't that sound like exactly what you need?
>
> Because that DF ID *is* practically the package ID as there's 1:1
> mapping between DF and a package, as you say above.
>
> Right?
>
> Now, it says
>
> [ 7.670791] smpboot: Max logical packages: 2
>
> on my Rome box but what you want sounds very much like the logical
> package ID and if we define that on AMD to be that and document it this
> way, I guess that should work too, provided there are no caveats like
> sched is using this info for proper task placement and so on. That would
> need code audit, of course...
>
The only use of logical_proc_id seems to be in hswep_uncore_cpu_init().
So I think maybe we can use this.
However, I think there are two issues.
1) The logical_proc_id seems like it should refer to the same type of
structure as phys_proc_id. In our case, this won't be true as
phys_proc_id would refer to the "socket" on AMD and logical_proc_id
would refer to the package/AMD NodeId.
2) The AMD NodeId is read during c_init()/init_amd(), so logical_proc_id
can be set here. But then logical_proc_id will get overwritten later in
topology_update_package_map(). I don't know if it'd be good to modify
the generic flow to support this vendor-specific behavior.
What do you think?
Thanks,
Yazen
next prev parent reply other threads:[~2020-09-16 19:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 20:01 [PATCH v2 0/8] AMD MCA Address Translation Updates Yazen Ghannam
2020-09-03 20:01 ` [PATCH v2 1/8] x86/CPU/AMD: Save NodeId on AMD-based systems Yazen Ghannam
2020-09-09 18:06 ` Borislav Petkov
2020-09-09 20:17 ` Yazen Ghannam
2020-09-10 10:14 ` Borislav Petkov
2020-09-14 19:20 ` Yazen Ghannam
2020-09-15 8:35 ` Borislav Petkov
2020-09-16 19:51 ` Yazen Ghannam [this message]
2020-09-17 10:37 ` Borislav Petkov
2020-09-17 16:20 ` Yazen Ghannam
2020-09-17 16:40 ` Borislav Petkov
2020-09-17 19:44 ` Yazen Ghannam
2020-09-17 20:10 ` Borislav Petkov
2020-09-03 20:01 ` [PATCH v2 2/8] x86/CPU/AMD: Remove amd_get_nb_id() Yazen Ghannam
2020-09-03 20:01 ` [PATCH v2 3/8] EDAC/mce_amd: Use struct cpuinfo_x86.node_id for NodeId Yazen Ghannam
2020-09-03 20:01 ` [PATCH v2 4/8] x86/MCE/AMD: Use defines for register addresses in translation code Yazen Ghannam
2020-09-03 20:01 ` [PATCH v2 5/8] x86/MCE/AMD: Use macros to get bitfields " Yazen Ghannam
2020-09-21 13:58 ` Borislav Petkov
2020-09-03 20:01 ` [PATCH v2 6/8] x86/MCE/AMD: Drop tmp variable " Yazen Ghannam
2020-09-23 8:05 ` Borislav Petkov
2020-09-23 16:05 ` Yazen Ghannam
2020-09-03 20:01 ` [PATCH v2 7/8] x86/MCE/AMD: Group register reads " Yazen Ghannam
2020-09-03 20:01 ` [PATCH v2 8/8] x86/MCE/AMD Support new memory interleaving modes during address translation Yazen Ghannam
2020-09-23 8:20 ` Borislav Petkov
2020-09-23 16:25 ` Yazen Ghannam
2020-09-25 7:22 ` Borislav Petkov
2020-09-25 19:51 ` Yazen Ghannam
2020-09-28 9:47 ` Borislav Petkov
2020-09-28 15:53 ` Yazen Ghannam
2020-09-28 18:14 ` Borislav Petkov
2020-09-29 13:21 ` Yazen Ghannam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200916195152.GA3042858@yaz-nikka.amd.com \
--to=yazen.ghannam@amd.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.