Page MenuHomeFreeBSD

arm64: Make SMP `spin-table` boot method work for more than Apple Silicon
Needs ReviewPublic

Authored by jhibbits on Dec 4 2023, 6:44 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Jul 4, 7:44 PM
Unknown Object (File)
Jun 16 2024, 2:57 AM
Unknown Object (File)
Jun 7 2024, 6:31 AM
Unknown Object (File)
Jun 2 2024, 3:50 PM
Unknown Object (File)
Jun 2 2024, 6:51 AM
Unknown Object (File)
Jun 1 2024, 6:13 PM
Unknown Object (File)
May 25 2024, 5:08 AM
Unknown Object (File)
May 23 2024, 2:23 AM
Subscribers

Details

Reviewers
kevans
andrew
manu
Group Reviewers
arm64
Summary

The spin-table AP boot method on arm64 uses a single shared release
address, which the BSP sets to the entry point. This is in contrast to
other platforms, such as powerpc, which utilize a separate release
address for each core, containing a multi-word descriptor. This
difference therefore requires that the AP holdoff be managed entirely by
the OS. Support this by adding a new ap_cpuid variable, holding the
64-bit cpu device tree reg value, which should map to the mpidr_el1,
masked out to the CPU affinity bits. With this, we also need a new
entry point to spin until the it's the given core's turn to let go.

Sponsored by: Juniper Networks, Inc.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 57111
Build 53999: arc lint + arc unit

Event Timeline

jhibbits retitled this revision from arm64: Make SMP `spin-table` boot method work to arm64: Make SMP `spin-table` boot method work for more than Apple Silicon.Dec 4 2023, 6:45 PM
sys/arm64/arm64/mp_machdep.c
119

I didn't put this into machdep.h or cpu.h because it's not a stable variable, its only purpose is AP hold-off, holding the "current" AP in bringup.

sys/arm64/arm64/locore.S
209
952–959

This is in the .init_pagetable section where you probably don't want it. It might be better to just move it to mp_machdep.c.

sys/arm64/arm64/mp_machdep.c
427

Are these needed? cpu_flush_dcache is a nop on arm64 so should probably be cpu_dcache_wb_range if they are.

sys/arm64/arm64/mp_machdep.c
427

You're right. Changing that.

sys/arm64/arm64/locore.S
209

Should be ldr x2, =CPU_AFF_MASK

I've thought about this and think we should only read ap_cpuid after the MMU is enabled. The same physical address should be mapped with the same memory type for all virtual addresses, however this isn't possible for ap_cpuid when the MMU is disabled.

This might need a new wfe/sev section to ensure the CPU is running.