linux-kernel - Re: [PATCH/RFC v1 0/2] Human readable performance event description in sysfs

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, 20 Jan 2010 14:41:40 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jamie Iles <jamie.iles@...ochip.com>, jpihet@...sta.com,
	p.osciak@...sung.com, will.deacon@....com,
	Michał Nazarewicz <m.nazarewicz@...sung.com>,
	linux-kernel@...r.kernel.org, kyungmin.park@...sung.com,
	mingo@...e.hu, m.szyprowski@...sung.com,
	linux-arm-kernel@...ts.infradead.org,
	Tomasz Fujak <t.fujak@...sung.com>
Subject: Re: [PATCH/RFC v1 0/2] Human readable performance event
	description in sysfs

On Wed, Jan 20, 2010 at 03:01:20PM +0100, Peter Zijlstra wrote:
> On Wed, 2010-01-20 at 13:55 +0000, Russell King - ARM Linux wrote:
> > 
> > Unfortunately, it isn't.  CPU identification has become a fairly murky
> > business on ARM that the information exported from /proc/cpuinfo can
> > no longer precisely identify the CPU itself.
> > 
> > For example, we just treat Cortex A8 and A9 as "ARMv7" because from the
> > kernel's point of view, they're the same. 
> 
> Would it make sense to extend arm's cpuinfo to include enough
> information so that userspace can indeed do this?

The idea that "I'm running on a Cortex A9" is no longer provided by the
new CPU ID scheme.  Instead, what's now provided is a set of registers
which describe various individual features of the CPU:

- ThumbEE ISA level, Jazelle ISA level, Thumb ISA level, ARM ISA level.
- Programmer model (not much here that userspace would be interested in)
- Debug model (memory mapped/co-processor, v6 debug architecture, v7 debug
  architecture.)
- Four 32-bit registers describing the memory model.

Note that pre-ARMv6k does not provide this information.  Plus, the
interpretation of these registers change between ARMv6k and ARMv7 -
and I wouldn't be surprised if the interpretation changes in the
future - just like the 'cache type' register completely changed format
on ARMv7.

> It seems to me userspace might care about the exact platform they're
> running on.

It may wanted to care at one time, but as time goes on, knowing what
the high-level chip is will be come irrelevent, and is actually the
wrong question.

The real questions that userspace needs to ask are the specific ones,
such as "what ARM ISA level is supported?  what Thumb ISA level is
supported?  what debug model is implemented?"

Given that history has shown that identification schemes on ARM change
in extremely annoying ways, I don't think decoding these registers to
some kind of textual representation for /proc/cpuinfo is the right
approach.  It might instead make more sense to just export the entire
set of CPU ID registers to userspace, and let userspace grapple with
the complexities of decoding the information it wants from them.
--
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/