docs/designs/fail-boot-on-hw-error.md

12 firmware to halt a system if an error log is created which calls out a piece of
13 hardware. The reason behind this is to ensure a system is not shipped to a
16 If the system has a hardware issue once shipped from manufacturing, then the BMC
17 firmware behavior should be to report the error, but allow the system to
20 OpenBMC firmware needs a mechanism to support this use case.
26 which the firmware would then query. These registry variables were only settable
27 by someone with admin authority to the system. These flags were not used outside
30 Extensions within phosphor-logging may process logs that do not always come
31 through the standard phosphor-logging interfaces (for example logs sent down by
32 the host). In these cases the system must still halt if those logs contain
39 - Provide a mechanism to cause the OpenBMC firmware to halt a system if a
40   phosphor-logging log is created with a inventory callout
41   - The mechanism to enable/disable this feature does not need to be an external
44   - The halt must be obvious to the user when it occurs
45     - The log which causes the halt must be identifiable
46   - The halt must only stop the chassis/host instance that encountered the error
47   - The halt must allow the host firmware the opportunity to gracefully shut
49   - The halt must stop the host (run obmc-host-stop@X.target) associated with
50     the error and attempt to leave system in the fail state (i.e. chassis power
52   - The chassis/host instance pair will not be allowed to power on until the log
54     - A BMC reset will clear this power on prevention
55 - Ensure the mechanism used to halt firmware on inventory callouts can also be
56   utilized by phosphor-logging extensions to halt firmware for other causes
57   - These causes will be defined within the extensions documentation
58 - Quiesce the associated host during this failure
67 Create a [phosphor-settingsd][2] setting,
72 Define a new D-Bus interface which will indicate an error has been created which
76 This interface will be hosted under a instance based D-Bus object
80 When an error is created via a phosphor-logging interface, the software will
83 phosphor-logging will create a `/xyz/openbmc_project/logging/blockX` D-Bus
85 under it. A mapper [association][3] between the log and this new D-Bus object
87 phosphor-logging.
90 responsible for the blocking. Other system specific policies could be placed in
94 See the phosphor-logging [callout][4] design for more information on callouts.
96 A new `obmc-host-graceful-quiesce@.target` systemd target will be started. This
98 start the `obmc-host-quiesce@.target` which will stop the host and move the host
106 developers to associate certain error logs with causing a halt to the system
117 The interfaces provided within phosphor-logging to handle the hardware callout
122 Currently this feature is a part of the base phosphor-logging design. If no one
123 other then IBM sees value, we could roll this into the PEL-specific portion of
124 phosphor-logging.
131 There will be no changes to system behavior unless a user turns on this new
139 Test cases will need to look for this new blocking D-Bus object and handle
142 [1]: https://lists.ozlabs.org/pipermail/openbmc/2020-February/020575.html
143 [2]: https://github.com/openbmc/phosphor-settingsd
145   https://github.com/openbmc/docs/blob/master/architecture/object-mapper.md#associations
147 …https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Common/Ca…
149   https://github.com/openbmc/phosphor-logging/blob/master/extensions/openpower-pels/README.md