linux-kernel - Re: [PATCH] loongarch: retrieve CPU package ID from PPTT when available

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>] [day] [month] [year] [list]

Message-ID: <f94fbe61-11b9-4fbc-a2a1-57a10547655a@aosc.io>
Date: Tue, 27 Jan 2026 22:16:39 +0800
From: Mingcong Bai <jeffbai@...c.io>
To: Rong Bao <rong.bao@...antle.top>, Huacai Chen <chenhuacai@...nel.org>
Cc: Kexy Biscuit <kexybiscuit@...c.io>, stable@...r.kernel.org,
 WANG Xuerui <kernel@...0n.name>, Yuli Wang <wangyuli@...ontech.com>,
 Yanteng Si <si.yanteng@...ux.dev>, Masahiro Yamada <masahiroy@...nel.org>,
 Hongliang Wang <wanghongliang@...ngson.cn>,
 Thierry Reding <treding@...dia.com>,
 Tianyang Zhang <zhangtianyang@...ngson.cn>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] loongarch: retrieve CPU package ID from PPTT when
 available

Hi Rong,

在 2026/1/23 23:56, Rong Bao 写道:
> Currently, the LoongArch CPU topology initialization code calculates
> each core's package ID by dividing its physical ID by
> loongson_sysconf.cores_per_package. This relies on the assumption that
> cores_per_package counts in the same domain as physical IDs.
> 
> On Loongson 3B6000 (XB612B0V_1.2), cores_per_package matches the visible
> core count -- 24 in this case. However, the physical IDs range from 0 to
> 31 in a noncontiguous fashion:
> 
>          $ cat /proc/cpuinfo | grep -i -F 'global_id'
>          global_id               : 0
>          global_id               : 1
>          global_id               : 4
>          global_id               : 5
>          global_id               : 6
>          global_id               : 7
>          global_id               : 8
>          global_id               : 9
>          global_id               : 10
>          global_id               : 11
>          global_id               : 14
>          global_id               : 15
>          global_id               : 16
>          global_id               : 17
>          global_id               : 20
>          global_id               : 21
>          global_id               : 22
>          global_id               : 23
>          global_id               : 26
>          global_id               : 27
>          global_id               : 28
>          global_id               : 29
>          global_id               : 30
>          global_id               : 31
> 
> Retrieve the exact package ID from ACPI PPTT when available, in the same
> style as retrieving the core ID and thread ID in parse_acpi_topology().
> Use this information in loongson_init_secondary() when PPTT readout is
> successful. The original division logic is kept as a fallback.
> 
> Cc: stable@...r.kernel.org
> Signed-off-by: Rong Bao <rong.bao@...antle.top>

Tested good on the following single-socket systems:

- Loongson XA61200_V1.1 (Loongson 3A6000-HV)
- Loongson AC612A0_V1.1 (Loongson 3C6000/S)
- Loongson N2K20Z0 (Loongson 2K2000, "Cloud Laptop")
- IPASON NL38-N11 (Loongson 3A6000, laptop)

... the following dual-socket systems:

- Loongson TD622E0 (Loongson 3C6000/D × 2)

... and of course, the offending platform:

- Loongson XB612B0_V1.2 (Loongson 3B6000, 12 cores)

I should note however, I found that the patch caused lscpu(1) to report 
incorrect processor topology on Loongson TD622E0:

   Thread(s) per core:        2
   Core(s) per socket:        64
   Socket(s):                 1

Whereas it should have been:

   Thread(s) per core:        2
   Core(s) per socket:        32
   Socket(s):                 2

Which, of course, due to the nature of this patch, was caused by 
incorrect PPTT data included in the firmware (this was fixed earlier 
today); NUMA topology reporting was not affected.

If this patch results in incorrect processor topology reports, similarly 
to what I ran into above, you should consult your system vendor for a 
firmware fix (or some sort of quirk should be shipped with distros - or 
the upstream somehow?).

With that,

Tested-by: Mingcong Bai <jeffbai@...c.io>
Tested-by: Xi Ruoyao <xry111@...111.site>

Best Regards,
Mingcong Bai