linux-kernel - RE: [PATCH] EDAC/{i10nm,skx,skx_common}: Support multiple clumps

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: <SJ1PR11MB60835F7CA3BB0430A4B116C0FC312@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 6 Dec 2024 21:24:29 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Meyer, Kyle" <kyle.meyer@....com>, "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
CC: "bp@...en8.de" <bp@...en8.de>, "james.morse@....com"
	<james.morse@....com>, "mchehab@...nel.org" <mchehab@...nel.org>,
	"rric@...nel.org" <rric@...nel.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] EDAC/{i10nm,skx,skx_common}: Support multiple clumps

> So, we're back to the original issue on systems with multiple UPI/QPI domains
> when NUMA is disabled.
>
> Systems with multiple UPI/QPI domains can't use source IDs to map devices
> to sockets. skx_get_src_id() will successfully read the source ID from PCI
> configuration space registers but it might not map to the correct socket because
> each UPI/QPI domain has identical repeating source IDs.
>
> For example, 8 sockets with 2 UPI/QPI domains:
>
> Socket 0 -> Source ID 0
> Socket 1 -> Source ID 1
> Socket 2 -> Source ID 2
> Socket 3 -> Source ID 3
> Socket 4 -> Source ID 0
> Socket 5 -> Source ID 1
> Socket 6 -> Source ID 2
> Socket 7 -> Source ID 3
>
> EDAC will successfully load, but it will not find the the corresponding device
> for errors on sockets 4 though 7 (for example, see skx_common.c:178).
>
> Looking at my original patch, EDAC will not load when a system has multiple UPI/
> QPI domains and NUMA is disabled. We fail early with "Failed to get package ID
> from NUMA information" instead of later when an error occurs.

Looks like there are four, mostly orthogonal, configuration possibilities:

1) System: Clumps vs. no-clumps
2) BIOS: Option to pick UMA vs. NUMA description to OS
3) Kernel configuration: CONFIG_NUMA=y vs. "not set"
4) Kernel x86 boot param: numa=off (or noacpi,nohmat) vs. no option

Maybe not all permutations make sense? '2' and '4' may be effectively the same?

Can this be solved for systems that have clumps, but Linux is ignoring NUMA-ness?

-Tony