Record MPIDR for all started cores to table and use this table as link
between arbitrarily assigned cpuid and real system position of given core.
MFC after: 1 month
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
Will this still work on the Juno where the boot cpu is not the first CPU in the dtb?
| sys/arm64/arm64/mp_machdep.c | ||
|---|---|---|
| 127 | You could put this into the pcpu structure. | |
| 426 | You should use CPU_AFF_MASK. We should have used it previously, I'm not sure why it wasn't. | |
| 447 | Extra space? | |
| 486 | This looks broken, it doesn't increment the cpu id for the boot CPU. I think it would be safer to put this check into start_cpu. | |
| 530 | Extra newline | |
Comment Actions
Boot CPU have always cpuid 0 so yes, it boots (i hope). I have disordered cpus nodes in my DTS and all looks OK.
| sys/arm64/arm64/mp_machdep.c | ||
|---|---|---|
| 127 | Nope, in view of D13864 we must be able to access this array before we known valid cpuid. But having a MPIDR also in pcpu structure doesn't sound bad. | |
| 426 | Yep, thanks. I missed CPU_AFF_MASK completely. | |
| 486 | The boot core have always cpuid=0 , so skipping it here is OK. But I forgot change initialization of 'cores' variable to 1 (at line 534 in new file). I will fix this in next version. | |
Comment Actions
Update to the final version. r359280 removed the need to access the cpu_mpidr table from the assembler. So eliminate it and insert the mpidr field into the pcpu structure as originally requested.
Comment Actions
Will this reorder the CPU IDs? One reason for the previous scheme because at least one Arm CPU has 4 little CPUs and 2 big. As it booted on the first big this would be CPU 4 in the DTB. By rotating we can keep the big CPUs together.
My preference would be to allow booting from pcpu[4], but haven't had the time to audit the code to check it doesn't hard code the boot CPU is 0.
Comment Actions
Yes, it changes CPU IDs. (For FDT case only. I assume that ACPI must always start on CPU0, even if I didn't find it in standard).
Please take in account that"
- actual FreeBSD must start on CPU0. imho, Nathan tried to fix this two/three years ago without success.
- numbering of CPUs in FDT is creative - is typically sequential, but some DT uses sparse numbering inspired by MPIDR. (see https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm64/freescale/fsl-lx2160a.dtsi?revision=361848&view=markup#l160 )
- renumbering in original code also failed if the boot processor was not the first in the cluster.
By all this, I think that we should take CPU ID as arbitrary value, without any relationship to physical topology and topology itself should be presented by cpu_topo().And other consumers (like GIC, scheduler, NUMA...) should build its own cpu_sets for given functionality. I don't see possibility how to represent all this by single number.