linux-kernel - Re: [PATCH v4 2/2] x86/amd: Fixup cpu_core_id for family17h downcore configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Jul 2017 13:02:49 +0700
From:   Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>
To:     Borislav Petkov <bp@...e.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, peterz@...radead.org,
        Yazen.Ghannam@....com, Andreas Herrmann <aherrmann@...e.com>
Subject: Re: [PATCH v4 2/2] x86/amd: Fixup cpu_core_id for family17h downcore
 configuration

Boris,

On 7/25/17 12:56, Borislav Petkov wrote:
> On Tue, Jul 25, 2017 at 12:51:53PM +0700, Suravee Suthikulpanit wrote:
>> Ok. Sure, it doesn't need be contiguous. But at least the cpu_core_id should
>> represent an ID that make some sense since it is used in the
>> arch/x86/kernel/smpboot.c: match_smt() and some other places. So, if it's
>> invalid for the downcore configuration (i.e. duplicated where it should not
>> be), we should at least clean this up.
> Ah right, we do use it for the SMT siblings. So yes, it should be
> correct for them. And I'm pretty sure the numbers we derive from the
> initial APIC ID are already good enough for that.
>

commit 08b259631b5a1d912af4832847b5642f377d9101
Author: Yazen Ghannam <Yazen.Ghannam@....com>
Date:   Sun Feb 5 11:50:22 2017 +0100

     x86/CPU/AMD: Fix Zen SMT topology

     After:

       a33d331761bc ("x86/CPU/AMD: Fix Bulldozer topology")

     our  SMT scheduling topology for Fam17h systems is broken, because
     the ThreadId is included in the ApicId when SMT is enabled.

     So, without further decoding cpu_core_id is unique for each thread
     rather than the same for threads on the same core. This didn't affect
     systems with SMT disabled. Make cpu_core_id be what it is defined to be.

Actually, this commit change how we derive the cpu_core_id fro family17h to use 
CPUID_Fn8000001E_EBX instead of from APIC ID for family17h and later.

Thanks,
Suravee