[PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs

[Ard Biesheuvel]

> On 17 jul. 2014, at 12:54, Will Deacon <will.deacon at arm.com> wrote:
> 
>> On Thu, Jul 17, 2014 at 11:46:24AM +0100, Marcus Shawcroft wrote:
>>> On 17/07/14 11:39, Peter Maydell wrote:
>>>> On 16 July 2014 16:57, Will Deacon <will.deacon at arm.com> wrote:
>>>> I don't have hugely strong opinions about this, but I don't see why it's
>>>> useful to print exactly the same line out `n' times; once for each CPU. We
>>>> only pass one set of hwcaps to ELF executables via auxv, so why do we need
>>>> to duplicate things here?
>>> 
>>> I think there are a couple of lines of argument here:
>>> 
>>> (1) Precedent from other architectures. Both 32-bit ARM and
>>> x86 have the feature-info be per-core; we should do the same
>>> for 64-bit ARM unless there's a really strong reason not to.
>> 
>> Agreed.
> 
> I don't really see the benefits of pretending that /proc/cpuinfo is remotely
> portable between architectures.
> 
>>> (2) Making this be not-per-CPU backs us into a corner. If we
>>> have the feature flags per-core, and it turns out that they're
>>> never ever different between cores even on heterogenous
>>> CPUs, there's no problem. If we have the feature flags be
>>> listed only once, and then in future we do want to support
>>> some minor form of heterogeny between cores, then we're
>>> stuck with a compatibility break because the format doesn't
>>> let us express that. (Perhaps there might be a big.LITTLE
>>> system where only the big cores had the crypto extensions,
>>> to pick a random possibility where the kernel doesn't need to
>>> care but userspace could take advantage by restricting itself
>>> to running on only the big cores). I think this makes the
>>> choice pretty straightforward, since there's basically no
>>> benefit to having only a single features line.
>> 
>> Agreed.
> 
> So the real question is: do we want to allow Linux to support features that
> exist only on a subset of cores in the system? The current thinking is that
> we truncate the advertised features to the common system subset, which means
> it will be the same on all cores, by definition. That allows hardware guys
> to build crazy systems that we can at least use, without imparting a world
> of pain onto software that needs to run on them.
> 
> I also think that we're backed into a corner regardless. We've seen how
> people ignore hwcaps (e.g. SWP), so they're likely to parse the caps for
> CPU0 and use that as an indication of the system capabilities.
> 
> Note that the features list *isn't* just the features supported by the CPU.
> It also takes into account the set of features supported by the kernel (e.g.
> we don't advertise VFP on ARMv7 if VFP context switching isn't enabled).

So obviously, we shouldn't use hwcaps derived from cpu #0 to report cpu capabilities for all cpus. Why can't we have a single hwcaps line, and then a capabilties line for each cpu containing the 'raw' capability flags read straight from the cpu in question?

-- 
Ard.