Redfish BIOS vs. PLDM BIOS

Redfish BIOS vs. PLDM BIOS

[Andrew Geissler]

We at IBM ran into an issue recently around BIOS entries.

We have a PLDM BIOS entry, pvm_stop_at_standby, which is used to tell the host
whether it should stop in a setup/standby state or continue to boot all the
way up to the operating systems.

We had identified a Redfish API[1] that fit with this function and mapped that
API to a D-Bus property which was then used by PLDM to fill in this BIOS
attribute.

Recently though we've been working on incorporating the bios-settings-mgr into
our code and into PLDM. That provides a generic Redfish API for setting these
BIOS values using key,value pairs.

The issue is that we now have a BIOS value, pvm_stop_at_standby, defined within
this generic schema that should not be set via the Redfish BIOS interface but
instead set via the Systems/system BootSource API we've been using all along.

We've found some other BIOS attributes like this as well, where PLDM has defined
something as a BIOS value but there is a non-BIOS interface in Redfish to
manipulate it. I believe this email thread from Ratan/Manoj is similar [2]

We were brainstorming a bit and the best solution seems to be to break up
the PLDM BIOS values. Either put the one's backed by non-BIOS Redfish API's into
a separate file or name them in a way they can be easily filtered. PLDM then
only reports the real BIOS values to bios-settings-mgr and therefore Redfish
will only shows this as settable via the generic BIOS Redfish interface.
From a host perspective, they all look like BIOS values but how they are set
via Redfish would differ based on the the type of BIOS value noted above.

PLDM would need to support both the generic bios-settings-mgr BIOS values as
well as these other D-Bus backed ones.

Thoughts? Sampa is going to get a discord chat going but there's a lot of
background here so figured I'd send that out via email.

[1]
# pvm_stop_at_standby Enabled
curl -k -H "X-Auth-Token: $TOKEN" -X PATCH https://${BMC_IP}/redfish/v1/Systems/system -d '{"Boot":{"BootSourceOverrideEnabled": "Continuous","BootSourceOverrideTarget": "BiosSetup"}}'

# pvm_stop_at_standby Disabled
curl -k -H "X-Auth-Token: $TOKEN" -X PATCH https://${BMC_IP}/redfish/v1/Systems/system -d '{"Boot":{"BootSourceOverrideEnabled": "Disabled","BootSourceOverrideTarget": "None"}}'

[2]: https://lore.kernel.org/openbmc/b2b4c23a-0be4-8b76-20a2-dc689161490c@linux.vnet.ibm.com/

Re: Redfish BIOS vs. PLDM BIOS

[Deepak Kodihalli]

Forgot to copy the list.

On Thu, Feb 4, 2021 at 1:16 PM Deepak Kodihalli
<deepak.kodihalli.83@gmail.com> wrote:
>
> Hi Andrew,
>
> On Wed, Feb 3, 2021 at 10:35 PM Andrew Geissler <geissonator@gmail.com> wrote:
> >
> > We at IBM ran into an issue recently around BIOS entries.
> >
> > We have a PLDM BIOS entry, pvm_stop_at_standby, which is used to tell the host
> > whether it should stop in a setup/standby state or continue to boot all the
> > way up to the operating systems.
> >
> > We had identified a Redfish API[1] that fit with this function and mapped that
> > API to a D-Bus property which was then used by PLDM to fill in this BIOS
> > attribute.
> >
> > Recently though we've been working on incorporating the bios-settings-mgr into
> > our code and into PLDM. That provides a generic Redfish API for setting these
> > BIOS values using key,value pairs.
> >
> > The issue is that we now have a BIOS value, pvm_stop_at_standby, defined within
> > this generic schema that should not be set via the Redfish BIOS interface but
> > instead set via the Systems/system BootSource API we've been using all along.
> >
> > We've found some other BIOS attributes like this as well, where PLDM has defined
> > something as a BIOS value but there is a non-BIOS interface in Redfish to
> > manipulate it. I believe this email thread from Ratan/Manoj is similar [2]
> >
> > We were brainstorming a bit and the best solution seems to be to break up
> > the PLDM BIOS values. Either put the one's backed by non-BIOS Redfish API's into
> > a separate file or name them in a way they can be easily filtered. PLDM then
> > only reports the real BIOS values to bios-settings-mgr and therefore Redfish
> > will only shows this as settable via the generic BIOS Redfish interface.
> > From a host perspective, they all look like BIOS values but how they are set
> > via Redfish would differ based on the the type of BIOS value noted above.
> >
> > PLDM would need to support both the generic bios-settings-mgr BIOS values as
> > well as these other D-Bus backed ones.
> >
> > Thoughts? Sampa is going to get a discord chat going but there's a lot of
> > background here so figured I'd send that out via email.
>
> As you've described, this is really a problem because there are
> multiple APIs within Redish to set these attributes, and to the host
> firmware these are all BIOS attributes. What's the issue if these
> attributes are also included in the Redfish generic BIOS model? The
> pldm daemon should be able to associate BIOS attributes to the
> bios-settings-mgr D-Bus model and/or other D-Bus models. However, I'm
> not sure if we really want to tackle the complexity of excluding
> certain attributes from the bios-settings-mgr D-Bus model.
>
> Thanks,
> Deepak