Mapping IPMI boot device selector to D-Bbus properties

[Stewart Smith]

Deepak Kodihalli <dkodihal at linux.vnet.ibm.com> writes:
> We recently discovered an issue in the way the IPMI boot device selector 
> (represented by a nibble in the boot flags) is mapped to the D-Bus
> model.

for anyone playing at home, this was caught by op-test:

git clone https://github.com/open-power/op-test-framework.git
cd op-test-framework
./op-test <insert auth details here> --run testcases.OpTestInbandIPMI.SkirootFullInbandIPMI.test_chassis_bootdev

and this test does pass on other BMC IPMI implementations (such as AMI).

Although the exact failure was only really an accident of the test
rather than on purpose.

A happy accident at least as it means we found a bug :)

> In the IPMI spec the boot device selector has options for both "boot 
> source" (default/disk/crdom/network) and "boot mode" 
> (default/bios/safe/diag). Since this isn't a bit-filed, you can't 
> override for eg both the source and mode at the same time. It's probably 
> debatable to say whether such a possibility is desirable or not (for eg 
> I may want to set the boot source as network by default, but want to 
> boot to safe mode the next boot , and revert back to network for 
> subsequent boots without having to set the device again).
>
> There are different D-Bus interfaces depicting the boot mode [1] and 
> boot source [2] though. So when the IPMI boot device is changed, the 
> ipmid code sets a relevant boot mode or source property. It's possible 
> that both can get set when someone for eg sets the device to cdrom and 
> then to bios. The issue is how should ipmid respond to a get boot 
> options command - there's no way for ipmid to aggregate information from 
> both D-Bus properties as in the IPMI spec only one of them can be 
> represented. Today ipmid always favors the boot source property if both 
> are set [3]. That's not what a user expects though, because the user 
> would expect his last override to go through.
>
> The solution I'm proposing is that if a set boot device is mapping to a 
> boot source, then reset the boot mode D-Bus property to default, or vice 
> versa. This way the ipmid code can determine which property is not at 
> the default value. It doesn't break the behavior from an IPMI spec 
> perspective because only one can be set at a point of time anyway, and 
> we'll consume the latest override to the boot device. Other solutions or 
> thoughts?

Do we know the behaviour of other IPMI implementations? My *guess* would
be is that they only track one bit of information and the boot mode will
override the previous request for boot source.

Perhaps the correct behaviour is to reset the temporary boot source when
boot mode is set and vice versa? It kind-of seems like that's the intent
from reading the IPMI spec, but I'd appreciate input and being proven
wrong :)

-- 
Stewart Smith
OPAL Architect, IBM.