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

In D48633#1114612, @olce wrote:

In D48633#1114603, @jhibbits wrote:

I don't think it's possible to have domain 0 unpopulated on powerpc. I do have a patch that implements the NUMAing of mmu_radix_page_array_startup(), but it didn't improve performance any measurable degree when I tested, so never followed through with pushing it.

I see. I've taken care of updating the code under #ifdef notyet as a future reference, just in case.

Can I change the argument to -1 here? This will in practice change nothing as long as domain 0 is populated and not too small.

I don't think it's possible to have domain 0 unpopulated on powerpc. I do have a patch that implements the NUMAing of mmu_radix_page_array_startup(), but it didn't improve performance any measurable degree when I tested, so never followed through with pushing it.

In D47312#1110694, @jhb wrote:

So if I'm reading this correctly, there are a couple of changes here that aren't quite described in the commit log:

1. In the existing interface, the "pat" operation (both ioctl and in-kernel) accepts a mask of a control operation and a timeout value. In the new interface, the pat interface only accepts the timeout and a new control operation handles things like resetting the watchdog. I actually think just splitting that change out into its own commit (i.e. adding the new function and ioctl) earlier in the series might be nicer (if it is indeed separable).

Ping, anyone?

Abandoned in favor of D48064.