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:	Wed, 26 Aug 2009 10:49:48 -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 18:14 -0700, Yinghai Lu wrote:
> Suresh Siddha wrote:
> > 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.
> 
> then you may get wrong phys_proc_id for amd system with apic id lifting.

Then we should add an exception for AMD systems too. And not change
generic code.

> A: phys_pkg_id:
> Default option:
> use cpu id to get initial apic id, and then use initial apic id to get phys_pkg_id.
> 
> exception:
> vsmp: need to use apic id to get phys_pkg_id, and apic id and initial apic id is not consistent. 
> 
> for AMD system with apic id lifting, initial apic id and apic is not consistent. but we should
> use initial apic id to get phys_pkg_id. and that is consistent to Default option.
> 
> B: c->apicid for real apic id?
> we already have c->initial_apicid, and c->apicid.
> 1. for amd system with apicid lifting, should use hard_smp_processor_id to get c->apicid.
> 2. for intel system (other than vsmp, and x445), c->apicid c->initial_apicid is the same, so could use hard_smp_processor_id

On the platforms which don't support cpuid leaf 0xb, apicid and initial
apicid might be potentially different if the bios changes the apicid.
And we don't want to depend on the bios to get the things correct. So
where it is not needed, we don't want to depend on the
hard_smp_processor_id() for topology detection.

In short, on all the platforms we want to use initial apic id for apicid
and phys_proc_id. And only on the required platforms like x445, vsmp,
some AMD platforms, we can have their own mechanisms.

> 3. for vsmp, and x445, do you want to have c->apicid to have real apic id or the same as initial apic_id?

On these platforms, c->apicid should be based on their real apic id.

> 
> this patch is trying to make c->apicid to have real apic_id.

Can you please modify the patch so that we can have exceptions for
needed platforms only?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ