Skip to content

Support soft shutdown via ACPI PWRBTN_STS - #1217

Draft
lifning wants to merge 1 commit into
masterfrom
lif/acpi-shutdown-ft-luiz
Draft

lifning wants to merge 1 commit into
masterfrom
lif/acpi-shutdown-ft-luiz

Conversation

@lifning

@lifning lifning commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

Changes the instance state put API to support the propolis-server behaviors specified by RFD 622.

(draft PR; just one thing still remaining: fix cause of migration-from-base phd-test failure (propolis-client is the new v7, so phd-runner can't talk to the v6 propolis-server artifact... i may be holding it wrong))

@lifning
lifning force-pushed the lif/acpi-shutdown-ft-luiz branch from f3aa4de to 2453efc Compare September 19, 2026 08:14
Implements behavior specified in RFD 622, based on earlier work on
platform support for ACPI fixed power button by @lgfa29.

This adds an optional `acpi_timeout_secs` parameter
to instance state PUT, which if specified will cause
propolis-server to send the guest an [ACPI fixed power
button](https://uefi.org/specs/ACPI/6.6/04_ACPI_Hardware_Specification.html#fixed-power-button)
signal. After sending this to the guest, propolis-server waits for the
guest to shut itself down for the specified number of seconds before
enqueueing the explicit hard-stop or hard-reset the request would have
otherwise been without the timeout parameter specified.

If an instance state PUT request to stop or reset is received while
shutting down, it is honored immediately, possibly interrupting the
guest's safer shutdown process (unmounting disks, et al).

If an instance state PUT with a timeout is received while still waiting
for a previously-requested ACPI shutdown, the newer request is ignored.

If a guest which is expected to be shutting down sends propolis *any*
CPU-halting event, be it the expected halt, a chipset-driven reset, or
a triple-fault, the action which was specified in the pending shutdown
request is taken, overriding what the guest's action would normally
imply absent the pending shutdown with with the authority of the user's
intent.\*

(\* In essence, we expect that if the control plane tells us the
instance should be turned off gently, it could well be because the
sled is about to be upgraded, and the customer is likely to want their
VM guests' filesystems to be left in as coherent a state as possible.
An unclean unmount from a triple-fault followed shortly by the system
rebooting, starting a filesystem repair, and then being interrupted
during *that* by a hard-cut of its power is unlikely to be a positive
customer experience)

Co-authored-by: Luiz Aoqui <lgfa29@gmail.com>
@lifning
lifning force-pushed the lif/acpi-shutdown-ft-luiz branch from 2453efc to 0b3e6b4 Compare September 19, 2026 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant