linux-kernel - Re: AMD topology broken on various 754/AM2+/AM3/AM3+ systems causes NB/EDAC/GART regression since 6.14

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251103181245.7745621f.michal.pecio@gmail.com>
Date: Mon, 3 Nov 2025 18:12:45 +0100
From: Michal Pecio <michal.pecio@...il.com>
To: Yazen Ghannam <yazen.ghannam@....com>
Cc: x86@...nel.org, regressions@...ts.linux.dev, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Mario Limonciello <mario.limonciello@....com>, Eric
 DeVolder <eric.devolder@...cle.com>, linux-kernel@...r.kernel.org
Subject: Re: AMD topology broken on various 754/AM2+/AM3/AM3+ systems causes
 NB/EDAC/GART regression since 6.14

On Mon, 3 Nov 2025 09:38:51 -0500, Yazen Ghannam wrote:
> > I have this AM4 system with some proprietary HP BIOS:
> > 
> > [02Fh 0047 001h]               Local Apic ID : 10
> > [037h 0055 001h]               Local Apic ID : 11
> > [03Fh 0063 001h]               Local Apic ID : 12
> > [047h 0071 001h]               Local Apic ID : 13
> > 
> > domain: Thread     shift: 0 dom_size:     1 max_threads:     1
> > domain: Core       shift: 4 dom_size:    16 max_threads:    16
> > domain: Module     shift: 4 dom_size:     1 max_threads:    16
> > domain: Tile       shift: 4 dom_size:     1 max_threads:    16
> > domain: Die        shift: 4 dom_size:     1 max_threads:    16
> > domain: DieGrp     shift: 4 dom_size:     1 max_threads:    16
> > domain: Package    shift: 4 dom_size:     1 max_threads:    16
> > 
> > It seems that pkgid is 0x1 here, which is not a problem because
> > it's single socket, but dunno if HP or somebody else couldn't do
> > similar things in an 8-socket system and end up with pkgid > 8.
> >   
> 
> So is this another bogus case?

No, it isn't bogus. It's a quad-core Carrizo APU with its four LAPICs,
but their numbers start from 0x10 rather than 0x00. And AFAIU, the
calculated pkgid vaule will be 1.

If HP or other vendor would do similar thing on an 8-socket system,
the assumption that (pkgid < 8) could no longer hold, even if the CPUs
are completely real.