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] [day] [month] [year] [list]

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

On Wed, Jan 20, 2010 at 04:26:47PM +0000, Jamie Lokier wrote:
> In practice, the list of capabilities works well on x86 in /proc/cpuinfo:
> 
>     flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor vmx est tm2 xtpr pdcm
> 
> They are based on the feature bits from the CPU's cpuid instruction,
> but the kernel does things like apply errata quirks to remove bits
> that don't work on a particular implementation and show the lowest common
> denominator when there are multiple CPUs.

You're assuming that there's a fixed set of feature bits on ARM.  There
aren't.

What you have is a main ID register up until ARMv6, which has about
four different encodings.  On some CPUs, this is the only ID register
offered, and within that subset, some different CPUs (eg, implemented
by different manufacturers, or indeed the same manufacturer) have the
same ID register value, despite being rather different.

>From ARMv6k and later, we have a different ID scheme, where we have
about 10 32-bit registers giving detailed information about various
aspects of the CPU - including five 32-bit registers for details about
the instruction set.

We know that some of the meanings of these registers has changed their
meaning - and I don't think there's a way to identify which meaning
should be applied to the registers (it seems to require reading lots
of different documents to sort out what CPUs implement which method.)

Frankly, it's a mess, and when you look at implementations, it turns out
to be unreliable.

> On ARM, it would be great to have a simple set of features in
> /proc/cpuinfo indicating which instruction sets are available (and
> reliable).

I think you've living in a dream world there.
--
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/