In D51771#1182758, @imp wrote:

Where / how is this used?

Address feedback.

Address feedback

Address feedback. The change to vm_radix_insert, etc, is untested still (will
test in my VM shortly).

Address feedback.

Address @jhb's feedback.

In D51623#1181603, @kib wrote:

In D51623#1181602, @jhibbits wrote:

In D51623#1181601, @kib wrote:

In D51623#1181462, @jhibbits wrote:

One global question I have, most likely you must execute the handoff and start executing the new kernel on AP, not BSPs. In other words. the reboot must migrate to AP if it not already did it.

Do you mean it needs to migrate to the BSP, and not run on the APs? kern_reboot() already binds to CPU_FIRST().

If you mean it should execute from an AP, is there a reason for that?

Yes, of course I mean 'kexec must occur on BSP'. Silly thinko.

I think the sched_bind(curthread, CPU_FIRST()) in kern_reboot() should suffice, then, but correct me if I'm wrong.

When we eventually add rescue support, to run from panic, that might need to change, but would likely be a different entry, too.

Generally CPU_FIRST() is not BSP, but it happen on amd64. On x86 we define BSP as cpuid == 0.

In D51623#1181601, @kib wrote:

In D51623#1181462, @jhibbits wrote:

One global question I have, most likely you must execute the handoff and start executing the new kernel on AP, not BSPs. In other words. the reboot must migrate to AP if it not already did it.

Do you mean it needs to migrate to the BSP, and not run on the APs? kern_reboot() already binds to CPU_FIRST().

If you mean it should execute from an AP, is there a reason for that?

Yes, of course I mean 'kexec must occur on BSP'. Silly thinko.

One global question I have, most likely you must execute the handoff and start executing the new kernel on AP, not BSPs. In other words. the reboot must migrate to AP if it not already did it.

In D51620#1181458, @imp wrote:

You don't need to get this reviewed.

Abandoned in favor of the kexec stack.

In D51622#1179455, @kib wrote:

In fact, I retract my proposal with the INIT IPI. If SMI is broadcasted, other CPUs would not enter the SMI handler, and the sending CPU most likely hang waiting for the reply.

So yes, the cli;hlt loop is the best, but it should be executed from the memory which is not overwritten during kexec.

I should add that this is sort of how Linux does it as well (synchronize, disable interrupts, go catatonic and hope for the best)

In D51622#1179431, @kib wrote:

In D51622#1179429, @kib wrote:

In D51622#1179405, @jhibbits wrote:

In D51622#1179347, @kib wrote:

Why do we need this at all? Why cannot you use e.g. stop_cpus() or stop_cpus_hard() or even smp_rendezvous() to do that? It can be done in MI, and definitely does not require new IPI vector.

The purpose of this is to make the CPU go catatonic so that it requires a core reset to continue. The handler disables all interrupts before going catatonic, so it requires the LAPIC INIT sequence to restore. We don't want the CPU to execute any other instructions until reset because the memory may have been overwritten.

Then explain this, at least as a comment in the code.

In D51622#1179347, @kib wrote:

Why do we need this at all? Why cannot you use e.g. stop_cpus() or stop_cpus_hard() or even smp_rendezvous() to do that? It can be done in MI, and definitely does not require new IPI vector.

Is there anything blocking this now?

Math checks out. Haven't tested, but looks correct to me. I'll test it later, and won't hold it up.

Eliminate (most of) the ifdef soup in linux_ioctl.h by following @imp's suggestion.

I'm not sure why this was never connected to the build, I would have fixed it during my IfAPI work if it were connected then.

Slightly cleaner would be to use a local variable for msg_len, and write it out at the end, but this is fine.

Address feedback from @ziaee.

Ping? Been a couple months, want to wrap it all up.

Split into D49182 and D49183