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]

Date:	Thu, 20 Aug 2009 11:56:33 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Alex Chiang <achiang@...com>
Cc:	"hpa@...or.com" <hpa@...or.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"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

On Wed, 2009-08-19 at 14:02 -0700, Alex Chiang wrote:
> I understand your point about keeping the output of /proc/cpuinfo
> close to what the cpuid instruction says.
> 
> But in regard to the particular field that we're talking about
> here -- 'physical id' -- that doesn't seem to be represented from
> cpuid anyway. We're stuffing an APIC ID into that field, even
> when we already have other APIC ID output.

For the current generation platforms, APIC ID's are typically from
cpuid, except for large SGI UV platforms etc.

> > For example, we shouldn't assume that original phys proc id's calculated
> > from cpuid etc need not be contiguous and start from 0 etc. This is
> > platform dependent and may vary from one version to another version of
> > processor etc.
> 
> Sorry, I'm having a hard time parsing this sentence. Do you mean
> to say:
> 
> 	we shouldn't assume that phys_proc_id calculated from
> 	cpuid are contiguous and start from 0
> 
> ?

yes.

> 
> I agree with you (although I thought that they should be 0-based)
> but this quirk addresses a specific platform, where I can assume
> certain things about the BIOS, etc.

What happens if for some reason, newer bios/newer cpu generations on
this platform start having holes in the physical id space? We can't rule
out these kind of changes and we don't want to go behind distros
requesting fixes.

> I agree with you in general, but again, this is a specific
> platform quirk where I have a good idea of what is a supported
> configuration.

I am just nervous about future bios changes etc.

> > Easiest route will be to add a new entry in /proc/cpuinfo
> 
> Well, if you remain unconvinced that fixing up 'physical id' is
> the proper thing to do, here are some alternate proposals:
> 
> 	/proc/cpuinfo/chassis id
> 	/sys/devices/system/cpu/$cpu/chassis id
> 	/sys/devices/system/cpu/$cpu/topology/chassis id
> 

I really like this alternate proposal. This is simple and straight
forward to everyone.

thanks,
suresh

--
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/