Power Restore Policy

[Andrew Geissler]

The BMC has the concept of a Power Restore Policy.  It’s defined
within https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml

The point of this policy is to define the host boot behavior by the
BMC if it is rebooted.  The policies are:
o AlwaysOn
o AlwaysOff
o Restore

What complicates things a bit is the scenario where the BMC is
rebooted, but the host is booted.  Rule number one in bmc management
firmware is don’t mess with the host if it’s up and running.  So
basically, if the host is up and running, and the bmc is rebooted, the
bmc should do no actions other then to get it’s chassis and host state
objects to reflect that of the chassis and host (on and running).

If the host is not running, then here’s what the policies mean:

o AlwaysOn -> Power on
o AlwaysOff -> Leave system in off state
o Restore -> Read last requested host state and re-request it

OBMC has an application, somewhat misnamed, discover_system_state
which enforces the AlwaysOn logic.  The Restore logic was put into
phosphor-host-state-manager but I don’t believe this is the correct
place for it.  It does it when it reads it’s persisted value for the
last requested state when it starts.  I’d like to move the Restore
logic in with the discover_system_state application.

The reasons are the following:
o discover_system_state’s service can easily be configured to not run
when the host is already running
o phosphor-host-state-manager has to be started always and early, so
that it can monitor for any state change requests (like in the case
where the bmc is rebooted while the host is still up).
o Having all the policy in a single application is more testable and obvious

https://github.com/openbmc/openbmc/issues/2210 is tracking this.

Thoughts or questions?

Andrew