linux-kernel - Re: [PATCH] x86: add /proc/cpuinfo/physical id quirks

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: <20090820215954.GH13061@ldl.fc.hp.com>
Date:	Thu, 20 Aug 2009 15:59:54 -0600
From:	Alex Chiang <achiang@...com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Andi Kleen <andi@...stfloor.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: add /proc/cpuinfo/physical id quirks

* H. Peter Anvin <hpa@...or.com>:
> On 08/20/2009 02:26 PM, Suresh Siddha wrote:
> > On Thu, 2009-08-20 at 14:20 -0700, Alex Chiang wrote:
> >> It turns out I need to rework my patch anyway because I need
> >> to think about the case where a user disables some cores in
> >> the BIOS, in which case my (fragile) table selection scheme
> >> falls apart.
> > 
> > These are the sort of reasons why we want topology detection
> > to be completely based on what cpuid instruction says and
> > nothing else.
> 
> I agree... if this ID is used for topology detection, we
> shouldn't replace it arbitrarily with information from BIOS
> just to hope that it matches the motherboard stencil.

Well, to be fair, in my patch, the phys_proc_ids remained
consistent for a given physical processor package.

That is, if all the cores in a socket initially started with
phys_proc_id X, they all ended up with phys_proc_id Y.
Additionally, no other cores in other sockets ended up with Y.
So in that sense, there was no real change in how we detected CPU
topology. All the core/thread/sibling ids remained correct and
unchanged.

Second, my patch wasn't sticking arbitrary information in from
BIOS; it was merely rearranging the existing phys_proc_ids.

> *Furthermore*, there is no reason why motherboard stencilAs are
> purely numeric... consider the rather obvious case of two rows
> of four CPUs; they may have CPU slots labelled A1, A2, A3, A4,
> B1, B2, B3, B4.  It might very well be the right thing to
> support arbitrary strings for platforms we recognize.

But yes, I do agree that this is a good point, and even here at
HP, we have other platforms with complex physical topologies.

Once you go down this path of thinking though, ACPI starts
looming, and that has other issues associated with it (in my
mind, mostly around the cleanliness of implementation as ACPI
starts poking its fingers everywhere).

> As such I think we should have a socket name field in both
> /proc/cpuinfo and sysfs.

Well, now we have 2 yeas (hpa and Suresh), 1 nay (Andi), and 1
"tell me what you'd like" (me ;)

/ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/