| Message ID | 1405524767-30220-6-git-send-email-mark.rutland@arm.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Jul 16, 2014 at 04:32:47PM +0100, Mark Rutland wrote: > The features are printed per-cpu to match the format used by other > architectures, and are derived from the (globally uniform) hwcaps. In > cases where this may report incorrect information, rework is required > elsewhere to function with varying instruction set support, and the > sanity checks should provide us with some advance notice (warnings and > TAINT_CPU_OUT_OF_SPEC). If we're lucky, such systems will never exist. [...] > - for_each_online_cpu(i) { > /* > * glibc reads /proc/cpuinfo to determine the number of > * online processors, looking for lines beginning with > * "processor". Give glibc what it expects. > */ > #ifdef CONFIG_SMP > - seq_printf(m, "processor\t: %d\n", i); > + seq_printf(m, "processor\t: %d\n", c); > #endif > + seq_printf(m, "implementer\t: 0x%02x\n", > + MIDR_IMPLEMENTOR(midr)); > + seq_printf(m, "variant\t\t: 0x%x\n", MIDR_VARIANT(midr)); > + seq_printf(m, "partnum\t\t: 0x%03x\n", MIDR_PARTNUM(midr)); > + seq_printf(m, "revision\t: 0x%x\n", MIDR_REVISION(midr)); > + > + /* dump out the processor features */ > + seq_puts(m, "features\t: "); > + for (i = 0; hwcap_str[i]; i++) > + if (elf_hwcap & (1 << i)) > + seq_printf(m, "%s ", hwcap_str[i]); 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? Put another way, we're really treating the hwcaps as a system property rather than a per-cpu property, so I think we should handle them as such. Will
On Wed, Jul 16, 2014 at 04:57:47PM +0100, Will Deacon wrote: > On Wed, Jul 16, 2014 at 04:32:47PM +0100, Mark Rutland wrote: > > The features are printed per-cpu to match the format used by other > > architectures, and are derived from the (globally uniform) hwcaps. In > > cases where this may report incorrect information, rework is required > > elsewhere to function with varying instruction set support, and the > > sanity checks should provide us with some advance notice (warnings and > > TAINT_CPU_OUT_OF_SPEC). If we're lucky, such systems will never exist. > > [...] > > > - for_each_online_cpu(i) { > > /* > > * glibc reads /proc/cpuinfo to determine the number of > > * online processors, looking for lines beginning with > > * "processor". Give glibc what it expects. > > */ > > #ifdef CONFIG_SMP > > - seq_printf(m, "processor\t: %d\n", i); > > + seq_printf(m, "processor\t: %d\n", c); > > #endif > > + seq_printf(m, "implementer\t: 0x%02x\n", > > + MIDR_IMPLEMENTOR(midr)); > > + seq_printf(m, "variant\t\t: 0x%x\n", MIDR_VARIANT(midr)); > > + seq_printf(m, "partnum\t\t: 0x%03x\n", MIDR_PARTNUM(midr)); > > + seq_printf(m, "revision\t: 0x%x\n", MIDR_REVISION(midr)); > > + > > + /* dump out the processor features */ > > + seq_puts(m, "features\t: "); > > + for (i = 0; hwcap_str[i]; i++) > > + if (elf_hwcap & (1 << i)) > > + seq_printf(m, "%s ", hwcap_str[i]); > > 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? > > Put another way, we're really treating the hwcaps as a system property > rather than a per-cpu property, so I think we should handle them as such. I agree. An argument would be that we expose per-cpu hwcap in /proc/cpuinfo so that whoever (human) looks at this can get an idea of what features are missing on some CPUs. The elf_hwcap exported to user via envp should only contain the common subset. But my worry is that code will start reading /proc/cpuinfo and make the wrong assumptions on heterogeneous systems, so I agree with Will's proposal of only printing the (common) CPU features once as a system property made available by the kernel.
On 16 July 2014 16:57, Will Deacon <will.deacon@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. (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. (3) CPU features really are per-core, so collapsing them down into a single line is not consistent with the line this series otherwise takes of "we just report the information the hardware provides without interpretation" (in particular the refusal to provide nice human readable CPU names). > Put another way, we're really treating the hwcaps as a system property > rather than a per-cpu property, so I think we should handle them as such. This is an implementation detail of the kernel, so you shouldn't be gratuitously exposing it to userspace if you can easily avoid doing so, as here. (The ELF HWCAP ABI obviously does assume homogeny and would need fixing in a future more heterogenous world.) If you wanted you could print a single "lowest common denominator features" line in addition to the per-CPU features information. thanks -- PMM
On 17/07/14 11:39, Peter Maydell wrote: > On 16 July 2014 16:57, Will Deacon <will.deacon@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. > (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. This patch is in itself an ABI break for anyone consuming /proc/cpuinfo. Making this be not-per-cpu just sets us up for another ABI break in the future, not ideal. Cheers /Marcus
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@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). Will
> On 17 jul. 2014, at 12:54, Will Deacon <will.deacon@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@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?
On 17 July 2014 11:54, Will Deacon <will.deacon@arm.com> wrote: > I don't really see the benefits of pretending that /proc/cpuinfo is remotely > portable between architectures. I'm not suggesting it's portable. I'm suggesting that you need a good reason to push backwards against a design decision made on other architectures. In particular, given that ARM is in general *more* likely to be heterogenous than x86 (given the existence of big.LITTLE), it seems baffling to try to move in a direction that denies the possibility of further heterogeneity in future. > 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've already made one suggestion (non-pervasive crypto). You could also envisage "feature bits" that effectively mean "things will be faster on this core" even if they still work on other cores too. > 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. Certainly userspace *can* do the wrong thing. That doesn't necessarily mean that the kernel should only ever provide the API equivalent of safety scissors... > 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). This is an argument for also advertising the lowest-common-denominator feature bits. (Do you want to argue for a single "features:" line plus per-core "extra-features:" lines?) thanks -- PMM
On Thu, Jul 17, 2014 at 12:12:48PM +0100, Peter Maydell wrote: > On 17 July 2014 11:54, Will Deacon <will.deacon@arm.com> wrote: > > I don't really see the benefits of pretending that /proc/cpuinfo is remotely > > portable between architectures. > > I'm not suggesting it's portable. I'm suggesting that you need > a good reason to push backwards against a design decision > made on other architectures. In particular, given that ARM is > in general *more* likely to be heterogenous than x86 (given > the existence of big.LITTLE), it seems baffling to try to move > in a direction that denies the possibility of further heterogeneity > in future. We're not denying the possibility of heterogeneity, we're trying to expose a consistent view of the system to userspace. Differences between cores should be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly passed off to userspace. > > 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've already made one suggestion (non-pervasive crypto). > You could also envisage "feature bits" that effectively mean > "things will be faster on this core" even if they still work on > other cores too. I don't believe that knowledge belongs in userspace. If you wanted to support crypto on such a system, then you advertise it as a system feature and migrate those tasks to the cores that support the instructions (in a similar manner to migrating the FPU on architecture that can share one). However, I'd prefer to start from a point where we *don't*' support such systems and actively dissuage people from building 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. > > Certainly userspace *can* do the wrong thing. That doesn't > necessarily mean that the kernel should only ever provide the > API equivalent of safety scissors... Userspace *will* do the wrong thing and it *will* turn the feature into useless baggage that we have to carry. > > 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). > > This is an argument for also advertising the lowest-common-denominator > feature bits. (Do you want to argue for a single "features:" line > plus per-core "extra-features:" lines?) That's what Ard brought up and I think it makes more sense that printing the same features line for each core. However, I question its usefulness and think it's ripe for misuse. Will
On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote: > We're not denying the possibility of heterogeneity, we're trying to expose a > consistent view of the system to userspace. Differences between cores should > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > passed off to userspace. On that basis, why report anything at all about invididual cores? Just have /proc/cpuinfo report "number of processors: 4" and no per-CPU information at all... -- PMM
On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote: > On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote: > > We're not denying the possibility of heterogeneity, we're trying to expose a > > consistent view of the system to userspace. Differences between cores should > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > > passed off to userspace. > > On that basis, why report anything at all about invididual cores? > Just have /proc/cpuinfo report "number of processors: 4" and > no per-CPU information at all... We lost a lot of time on this already (given the internal threads). So my proposal is to go ahead with Mark's patch with per-CPU features. They currently just include the same elf_hwcap multiple times. If we ever need to present different features, the conditions would be: 1. Never report more than elf_hwcap 2. elf_hwcap can only include non-symmetric features *if* Linux gets a way to transparently handle migration or emulation It basically means that Linux would not rely on the user space to make informed decisions on where to run a thread and avoid SIGILL.
On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote: > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote: > > On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote: > > > We're not denying the possibility of heterogeneity, we're trying to expose a > > > consistent view of the system to userspace. Differences between cores should > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > > > passed off to userspace. > > > > On that basis, why report anything at all about invididual cores? > > Just have /proc/cpuinfo report "number of processors: 4" and > > no per-CPU information at all... > > We lost a lot of time on this already (given the internal threads). So > my proposal is to go ahead with Mark's patch with per-CPU features. They > currently just include the same elf_hwcap multiple times. If we ever > need to present different features, the conditions would be: > > 1. Never report more than elf_hwcap > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a > way to transparently handle migration or emulation ... making the point of a per-cpu field entirely pointless ;) Will
On Thu, Jul 17, 2014 at 06:28:58PM +0100, Will Deacon wrote: > On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote: > > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote: > > > On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote: > > > > We're not denying the possibility of heterogeneity, we're trying to expose a > > > > consistent view of the system to userspace. Differences between cores should > > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > > > > passed off to userspace. > > > > > > On that basis, why report anything at all about invididual cores? > > > Just have /proc/cpuinfo report "number of processors: 4" and > > > no per-CPU information at all... > > > > We lost a lot of time on this already (given the internal threads). So > > my proposal is to go ahead with Mark's patch with per-CPU features. They > > currently just include the same elf_hwcap multiple times. If we ever > > need to present different features, the conditions would be: > > > > 1. Never report more than elf_hwcap > > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a > > way to transparently handle migration or emulation > > ... making the point of a per-cpu field entirely pointless ;) Well, if we can support such features in a transparent way, /proc/cpuinfo becomes more informative (e.g. user wondering why a process runs only on certain CPUs). But to be clear (and I think we are aligned), I don't trust user space to parse all processors in /proc/cpuinfo and make an informed selection of CPU affinity to avoid SIGILL. Yet another option would be to have a single features/hwcap line and present the extra features in a human (and only human) readable form (e.g. some haiku that changes with every kernel release ;)).
On Fri, Jul 18, 2014 at 10:27:44AM +0100, Catalin Marinas wrote: > On Thu, Jul 17, 2014 at 06:28:58PM +0100, Will Deacon wrote: > > On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote: > > > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote: > > > > On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote: > > > > > We're not denying the possibility of heterogeneity, we're trying to expose a > > > > > consistent view of the system to userspace. Differences between cores should > > > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly > > > > > passed off to userspace. > > > > > > > > On that basis, why report anything at all about invididual cores? > > > > Just have /proc/cpuinfo report "number of processors: 4" and > > > > no per-CPU information at all... > > > > > > We lost a lot of time on this already (given the internal threads). So > > > my proposal is to go ahead with Mark's patch with per-CPU features. They > > > currently just include the same elf_hwcap multiple times. If we ever > > > need to present different features, the conditions would be: > > > > > > 1. Never report more than elf_hwcap > > > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a > > > way to transparently handle migration or emulation > > > > ... making the point of a per-cpu field entirely pointless ;) > > Well, if we can support such features in a transparent way, > /proc/cpuinfo becomes more informative (e.g. user wondering why a > process runs only on certain CPUs). > > But to be clear (and I think we are aligned), I don't trust user space > to parse all processors in /proc/cpuinfo and make an informed selection > of CPU affinity to avoid SIGILL. > > Yet another option would be to have a single features/hwcap line and > present the extra features in a human (and only human) readable form > (e.g. some haiku that changes with every kernel release ;)). Or just have the single features line, then the per-cpu line can be called `flags' or something, like Ard suggested. If userspace decides to parse flags, it deserves all the pain that it gets. Will
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index edb146d..aa1b4f7 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -448,39 +448,34 @@ static const char *hwcap_str[] = { static int c_show(struct seq_file *m, void *v) { - int i; + int c, i; - seq_printf(m, "Processor\t: %s rev %d (%s)\n", - cpu_name, read_cpuid_id() & 15, ELF_PLATFORM); + for_each_online_cpu(c) { + struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, c); + u32 midr = cpuinfo->reg_midr; - for_each_online_cpu(i) { /* * glibc reads /proc/cpuinfo to determine the number of * online processors, looking for lines beginning with * "processor". Give glibc what it expects. */ #ifdef CONFIG_SMP - seq_printf(m, "processor\t: %d\n", i); + seq_printf(m, "processor\t: %d\n", c); #endif + seq_printf(m, "implementer\t: 0x%02x\n", + MIDR_IMPLEMENTOR(midr)); + seq_printf(m, "variant\t\t: 0x%x\n", MIDR_VARIANT(midr)); + seq_printf(m, "partnum\t\t: 0x%03x\n", MIDR_PARTNUM(midr)); + seq_printf(m, "revision\t: 0x%x\n", MIDR_REVISION(midr)); + + /* dump out the processor features */ + seq_puts(m, "features\t: "); + for (i = 0; hwcap_str[i]; i++) + if (elf_hwcap & (1 << i)) + seq_printf(m, "%s ", hwcap_str[i]); + seq_puts(m, "\n\n"); } - /* dump out the processor features */ - seq_puts(m, "Features\t: "); - - for (i = 0; hwcap_str[i]; i++) - if (elf_hwcap & (1 << i)) - seq_printf(m, "%s ", hwcap_str[i]); - - seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24); - seq_printf(m, "CPU architecture: AArch64\n"); - seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15); - seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff); - seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15); - - seq_puts(m, "\n"); - - seq_printf(m, "Hardware\t: %s\n", machine_name); - return 0; }
Currently reading /proc/cpuinfo will result in information being read out of the MIDR_EL1 of the current CPU, and the information is not associated with any particular logical CPU number. This is problematic for systems with heterogeneous CPUs (i.e. big.LITTLE) where MIDR fields will vary across CPUs, and the output will differ depending on the executing CPU. This patch reorganises the code responsible for /proc/cpuinfo to print information per-cpu. In the process, we perform several cleanups: * Property names are coerced to lower-case (to match "processor" as per glibc's expectations). * Property names are simplified and made to match the MIDR field names. * Revision is changed to hex as with every other field. * The meaningless Architecture property is removed. * The ripe-for-abuse Machine field is removed. The features are printed per-cpu to match the format used by other architectures, and are derived from the (globally uniform) hwcaps. In cases where this may report incorrect information, rework is required elsewhere to function with varying instruction set support, and the sanity checks should provide us with some advance notice (warnings and TAINT_CPU_OUT_OF_SPEC). If we're lucky, such systems will never exist. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Marcus Shawcroft <marcus.shawcroft@arm.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Will Deacon <will.deacon@arm.com> --- arch/arm64/kernel/setup.c | 39 +++++++++++++++++---------------------- 1 file changed, 17 insertions(+), 22 deletions(-)