Decode and print the ID registers on boot

[andrew]

Summary

This decodes and prints the ID registers on boot. It waits until all CPUs have read their registers before printing the information. We only print the registers that differ from cpu0.

[andrew]

This will print something similar to the following near the end of the boot log.

CPU  0: Cavium Thunder r0p1 affinity:  0  0
 Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
 Instruction Set Attributes 1 = <0>
         Processor Features 0 = <GIC,AdvSIMD,Float,EL3,EL2,EL1,EL0>
         Processor Features 1 = <0>
      Memory Model Features 0 = <4k Granule,Unknown 16k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,256TB PA>
      Memory Model Features 1 = <0x20>
             Debug Features 0 = <6 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
             Debug Features 1 = <0>
         Auxiliary Features 0 = <0>
         Auxiliary Features 1 = <0>
CPU  1: Cavium Thunder r0p1 affinity:  0  1
...
CPU 47: Cavium Thunder r0p1 affinity:  2 15

[andrew]

Fix decoding of the ID_AA64MMFR0_EL1 TGran16 field (16k granule)

[emaste]

We might want to reduce the verbosity later on (bootverbose) but I think the info is good to have by default for now.

[kib]

Also, do you envision running on the non-symmetric MP configurations, like big.LITTLE configs ? Can we enumerate different groups of feature-same CPUs and print features for each group ? Right now you would trigger the printing of different features registers for all CPUs, which is somewhat spammy on machines with expected config of >= 40 cores.

I wanted to port cpuctl(4) and cpucontrol(8) to ARM, and use it to export feature registers to userspace. I do not think that we provide a way for usermode to enumerate the features.

sys/arm64/arm64/identcpu.c

83 ↗

(On Diff #11759)

Is this alignment really needed ? The data structure is not very popular, and it is r/o anyway.

[andrew]

In D4725#100255, @emaste wrote:

We might want to reduce the verbosity later on (bootverbose) but I think the info is good to have by default for now.

It's no more verbose than amd64, they both print a

In D4725#100457, @kib wrote:

Also, do you envision running on the non-symmetric MP configurations, like big.LITTLE configs ? Can we enumerate different groups of feature-same CPUs and print features for each group ? Right now you would trigger the printing of different features registers for all CPUs, which is somewhat spammy on machines with expected config of >= 40 cores.

For many of the registers if they are different it could be considered a non-supported configuration. Linux has checks for this & prints a warning. I would expect to need to refine the printing of these registers to a set of common features, and a set of per-cluster features.

I wanted to port cpuctl(4) and cpucontrol(8) to ARM, and use it to export feature registers to userspace. I do not think that we provide a way for usermode to enumerate the features.

We would need to look to see what userland would need to know that it can't detect by itself.

[andrew]

sys/arm64/arm64/identcpu.c

83 ↗

(On Diff #11759)

I added it to ensure two CPUs can write to the struct without locking as two cores may share a cacheline.

[kib]

sys/arm64/arm64/identcpu.c

83 ↗

(On Diff #11759)

I do not understand this statement. Why would the alignment needed for this ? AFAIS, each CPU writes to its own structure, there is no field updates, only writes, and writes to the naturally-aligned integer variables are atomic.