linux-kernel - Re: [PATCH] x86: use hard_smp_processor_id to get apic id in identify

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: <1251240835.2636.28.camel@sbs-t61>
Date:	Tue, 25 Aug 2009 15:53:55 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>
Subject: Re: [PATCH] x86: use hard_smp_processor_id to get apic id in
 identify_cpu -v2

On Tue, 2009-08-25 at 15:06 -0700, Yinghai Lu wrote:
> 
> and leave phys_proc_id to use initial apic id.

No. We need to be consistent for both phys_proc_id and apicid
computations.

i.e., if the bios changes the apic id's and those updated apic id's are
not reflected in the initial apic id, then we need to use
hard_smp_processor_id() for both phys_proc_id and apicid computations.

On the other platforms (default option) we need to use initial apic id
(returned by cpuid).

> -v2: update the one in detect_extended_topology too.

This is not required. On these platforms, initial_apicid will be updated
(along with the physical apicid) if there are any bios modifications.

Instead of this patch, what we need to do is: Just like the vsmp change,
we need to override the phys_pkg_id routine for the platforms where the
bios will modify apic id's and where cpuid doesn't reflect the bios
modification (for example IBM x445 system etc)

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/