Resetting and Shutting Down (Reset and ACPI Power States)

x86 offers no single instruction for either resetting or powering off a machine, unlike halting a single CPU (hlt) or triggering an exception, both of which have direct, documented instruction-level support; a kernel deliberately restarting or shutting down the whole system instead has to go through one of several indirect mechanisms, none of them universally available on every board.

Resetting

The classic mechanism repurposes the 8042 keyboard controller, the same chip the A20 line already covers pulsing for an unrelated purpose: writing command byte 0xFE to port 0x64 pulses the controller’s reset line, which most chipsets wire directly to the CPU’s own reset input.

; classic 8042 reset
in  al, 0x64
test al, 2         ; wait for the input buffer to be clear
jnz  $-2
mov al, 0xFE
out 0x64, al        ; pulse the reset line

A more modern, more reliable path goes through ACPI’s FADT table, which carries a dedicated RESET_REG field (a generic address, commonly a port I/O or memory-mapped register depending on the platform) and a RESET_VALUE byte: writing that specific value to that specific register triggers a platform-defined reset sequence firmware has already validated for the exact board it’s running on, side-stepping the keyboard-controller trick’s dependency on hardware some newer systems no longer wire the same way at all.

The triple fault as a last resort

Deliberately causing a triple fault, an exception occurring while the CPU is already trying to handle a double fault, forces most x86 implementations to reset as a hardware-level failsafe, without any explicit reset instruction or register write involved at all: loading a deliberately invalid (zero-limit) IDT and then executing any instruction that raises an interrupt is a reliable way to trigger one.

lidt [null_idtr]   ; a descriptor with limit = 0
int 0x03            ; any interrupt attempt now faults, cascading to triple fault

This is treated as a last resort specifically because it isn’t really a reset mechanism at all, just a well-known consequence of exhausting the CPU’s own exception-handling machinery; Emulating & Debugging already covers QEMU’s -no-reboot flag largely because this exact failure mode, whether triggered deliberately or by an actual bug, is common enough during kernel development to need a way to freeze it instead of watching the machine silently restart.

Why powering off is a different, harder problem

None of the mechanisms above actually cut power to the machine; a reset restarts execution from the beginning without ever removing power, while genuinely powering off requires cooperating with the platform’s own power management logic to do so safely. On any ACPI-capable system, that means invoking the _S5 method, defined in AML inside the DSDT, which sets the specific values PM1a_CNT (and, where present, PM1b_CNT) need to actually transition the platform into the S5 (soft-off) power state: unlike the fixed-offset tables a kernel can parse without an interpreter, _S5’s exact values are board-specific and only discoverable by executing (or at minimum, evaluating) the relevant AML method, which is precisely the interpreter ACPI already identifies as out of scope for most hobby kernels. A kernel that hasn’t implemented an AML interpreter is left with no clean way to power off at all: some simply reset and rely on firmware or the user to cut power manually, while others hardcode the PM1a_CNT port and value for one specific, already-tested board or emulator, a fragile approach that only works on hardware it was never actually meant to generalize to.

Implementation notes

QEMU exposes a convenient shortcut around this entire problem for development purposes: writing a specific value to I/O port 0xF4 (the “isa-debug-exit” device, added with -device isa-debug-exit,iobase=0xf4 and not present by default) cleanly exits the emulator instead of requiring a real ACPI power-off sequence, useful specifically for automated testing where a kernel needs to signal “done” without implementing real shutdown at all. On real hardware, or an emulator without that debug device enabled, a kernel unable to invoke _S5 and unwilling to leave the machine simply spinning has essentially two honest options: reset via the FADT register above and let the user power off manually, or print a message telling the user it’s now safe to do so, rather than silently pretending to shut down when the mechanism to actually do it isn’t implemented.

References

^ UEFI Forum, ACPI Specification, Chapter 4 (FADT reset register) and Chapter 7 (system power states, including the S5 soft-off state and the _S5 object).

Resetting and Shutting Down (Reset and ACPI Power States)

Resetting

The triple fault as a last resort

Why powering off is a different, harder problem

Implementation notes

References

See also