rebooting != rebooting, but rather 'going through shutdown path'.

ofwfb needs the following properties to work correctly:

In D15818#1253597, @tpearson_raptorengineering.com wrote:

In D15818#1253535, @fuz wrote:

I have tested this patch in an adapted form on ppc64le FreeBSD 15.0 and it crashes early on boot. This is a Raptor Blackbird. @tpearson_raptorengineering.com, any idea?

Since we don't provide Open Firmware interfaces on PowerNV systems, that makes some sense. What we do provide (at least for certain video controllers) is a linear framebuffer available at the address listed in the device tree.

If that's used any more often than these two locations, we may want to add a STACK_ALIGNMENT macro.

Please MFC this to 15 and 14 as well.

Adding the wider powerpc umbrella, so others can take a look as well.

The type NULL checks are good. I think the whole of the changes for pmu_send() are a bit overkill. Could you test with just the one line I pointed out, and the rest reverted?

Impressive

Avoid the extra release_host/acquire_host, since we know it's already in that taken state.

Isn't make.conf also read for userspace builds and ports? I think we still support 32-bit userland. Would there be a corresponding change to remove the i386 bits as well?

I can't speak from authority on this, the original change almost predates my joining. @nwhitehorn made the change, and judging by the timing it was during his powerpc64 bringup, so likely related to some G5 or POWER4 issues encountered during his work. It's possible the real problem has been ironed out in the past 14 years.

Committed as a935c2a63 (don't feel like reverting and updating the commit message)

Address feedback. I hope I got everything.

RANDOM_KEYBOARD and RANDOM_MOUSE can be masked away by sysctls. What is the need to remove them this way?

Address feedback from @ziaee and @0mp. Thanks!

I'd make the summary more like: dev/ofw: Register ofw_cpu xref.

In D51622#1216461, @kib wrote:

I really become curious in which way firmware parks APs after the initial configuration. Coreboot might have something for this.

And indeed, there is very interesting https://github.com/coreboot/coreboot/blob/main/src/cpu/x86/lapic/lapic_cpu_stop.c that is used to park APs. From my reading, they send INIT IPI to itself, which, by the claim in the source file, is equivalent to asserting the INIT# pin.

In D51622#1179546, @kib wrote:

The loop is only "Just in case" an interrupt comes in that's not disabled (not being an x86 guy, I don't know what's disabled or not with disable_intr() and lapic_disable()). If nothing can come in, then there's no need for the safe memory, since once it halts it's dead.

As I said below, I believe SMI is still possible even in 'cli;hlt' loop. On AMD there is a way to disable SMI and NMI, but I do not think the method to do that is usable for kexec, and there is also Intel without something equivalent.

Address @kib's feedback. kexec_do_reboot() no longer takes an argument, and hasn't even in the first commit, so remove the argument from the prototype. Removed the wbinvd from the trampoline.

Address @kib's feedback further. I didn't reproduce the problem we solved with mfence, so removed that.

Address @kib's feedback.

In D51623#1209399, @kib wrote:

I might suggest, to not delay the commit even more, simply refuse kexec for now if we are in LA57. Then somebody would work out the missing code in the trampoline later.

In D51623#1209045, @kib wrote:

It seems that you always build 4-level intermediate page table. Wouldn't it blow up if the source kernel is running in LA57 mode? [Kernel always expect LA48 on start nonetheless]

Address feedback. I hope I got it all now.

Address feedback on ioctl list.

Address feedback. I think I got it all.

Further updates. vdso maps correctly.

Address feedback from @kib and @brooks.

Address feedback. I think I got it all.