* Borislav Petkov <b...@suse.de> wrote:
> On Thu, Jul 20, 2017 at 03:29:28AM -0500, Suravee Suthikulpanit wrote:
> > For family17h, current cpu_core_id is directly taken from the value
> > CPUID_Fn8000001E_EBX[7:0] (CoreId), which is the physical ID of the
> > core within a die. However, on system with downcore configuration
> > (where not all physical cores within a die are available),
> > this could result in the case where cpu_core_id > (cores_per_node - 1).
> >
> > Fix up the cpu_core_id by breaking down the bitfields of CoreId,
> > and calculate relative ID using available topology information.
> >
> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>
> > ---
> > arch/x86/kernel/cpu/amd.c | 61
> > ++++++++++++++++++++++++++++++++++-------------
> > 1 file changed, 45 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > index bb5abe8..e7de105 100644
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -310,38 +310,67 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
> >
> > /* get information required for multi-node processors */
> > if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
>
> Please carve this whole TOPOEXT-specific logic out, into a separate
> function, say __get_topoext() or so, for better readability/easier
> review.
Also please do the factoring out in a separate preparatory cleanup patch, so
that
we can see the two changes isolated.
Thanks,
Ingo
