linux-kernel - Re: [RFC] Add Arm cpu topology definition

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, 22 Jun 2011 10:17:27 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Stephen Boyd <sboyd@...eaurora.org>
Cc:	Vincent Guittot <vincent.guittot@...aro.org>,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC] Add Arm cpu topology definition

On Tue, Jun 21, 2011 at 01:36:15PM -0700, Stephen Boyd wrote:
> On 06/16/2011 11:54 PM, Vincent Guittot wrote:
> > On 16 June 2011 21:40, Stephen Boyd <sboyd@...eaurora.org> wrote:
> >> The ARM ARM says these fields are IMPLEMENTATION DEFINED meaning that
> >> different vendors may attribute different meaning to these fields if
> >> they wish. Does that mean this should be a platform_*() function?
> >>
> > The ARM ARM also provides a recommended use of the fields of this
> > register and the TRM of each Cortex adds some details. On the cortex
> > A9, each platform can only set the value of the Cluster ID with the
> > CLUSTERID pins. I have tried to consolidate the value of MPIDR  across
> > several platforms and they all match with the description.
> >
> > Have you got an example of a MPIDR register which doesn't match with
> > the implementation ?
> 
> Not that I know of. I'm more concerned with how the ARM ARM has two
> recommended usages for these fields depending on virtualization or not.
> I suppose we can handle that issue when it arises (or does your
> implementation already handle that?)

According to the ARM ARM:

	MPIDR provides a mechanism with up to three levels of affinity
	information, but the meaning of those levels of affinity is
	entirely IMPLEMENTATION DEFINED.

So we can't really tell the meaning of the affinity bits. There are two
recommended ways indeed (with or without virtualisation) which are not
that different with regards to the topology (just introducing another
level for virtual CPUs).

But I think a more general solution would be for the CPU topology to be
provided via the FDT.

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