* Exposing BIOS attributes to a remote management console
@ 2020-02-08 8:28 Deepak Kodihalli
[not found] ` <48777ea3-0af2-4725-9304-64ae4edb71d9@email.android.com>
0 siblings, 1 reply; 4+ messages in thread
From: Deepak Kodihalli @ 2020-02-08 8:28 UTC (permalink / raw)
To: openbmc
Hi,
To enable remote updates (via a remote management console that talks to
the BMC) to the host firmware's BIOS settings table on IBM systems,
we're thinking of the following flow:
a) The host firmware sends down a BIOS settings table to the BMC using
PLDM [1].
b) The BMC uses phosphor-settingsd [2] as the backend to store BIOS
attributes on D-Bus.
c) Bmcweb implements the Redfish BIOS schema [3] to enable remote
reads/writes on the BIOS attributes.
However, c) is a problem because one needs to write YAML files [4] for
the BMC to determine what D-Bus objects to make corresponding to the
BIOS attributes. This requires a unique D-Bus interface *per* BIOS
attribute. This means the BMC must have prior knowledge about the BIOS
attributes.
I don't think that's the right way to go about this for two reasons. One
- this creates a lockstep dependency on the host firmware when the BIOS
settings table needs to be updated, and two - I think the OpenBMC
implementation of this must be able to receive (via PLDM/IPMI/other
standard in-band means) a set of BIOS attributes from different BIOS
firmware stacks dynamically and expose them for out of band updates,
without having prior/build-time knowledge of those attributes. So I
think this calls for a different kind of D-Bus interface/infrastructure
than what the phosphor-settingsd app relies on. Something that enables
the BMC to add to D-Bus a BIOS attribute dynamically, knowing it's name,
type and default value.
Any thoughts on this flow? I'm also curious to know if the Redfish BIOS
schema/attribute registry model requires the BMC to have prior knowledge
about the system BIOS attributes to update the registry. This wasn't
obvious to me from a quick read of the schema.
Thanks,
Deepak
[1]
https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf
[2] https://github.com/openbmc/phosphor-settingsd
[3] https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json
[4]
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/settings/phosphor-settings-defaults/defaults.yaml
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: FW: Exposing BIOS attributes to a remote management console
[not found] ` <1504A9E7C77EF44697F386AD61B16260152FEBA5@BGSMSX105.gar.corp.intel.com>
@ 2020-02-10 10:49 ` Sekar, Suryakanth
2020-02-11 8:52 ` Deepak Kodihalli
0 siblings, 1 reply; 4+ messages in thread
From: Sekar, Suryakanth @ 2020-02-10 10:49 UTC (permalink / raw)
To: openbmc, Deepak Kodihalli, suryakanth.sekar
[-- Attachment #1: Type: text/plain, Size: 3878 bytes --]
Hi Deepak,
OOB BIOS high level config design doc is in progress. I will send for
review soon.
Yes, we need to support all interface -IPMI/ MCTP/ Redfish Host interface.
If BIOS is not booted at all. BMC wont have any attribute info. It will
be empty in BMC side.
BIOS must provide BIOS OOB capability via KCS interface in early boot stage.
Like supported proprietary BIOS attribute file format or PLDM support
via MCTP or
Redfish BIOS attribute registry format to the BMC.
BIOS must send the master BIOS attributes file(Intel properitary - XML
type 0)
via KCS interface or all attributes details via Bios configuration PLDM
via MCTP or
Redfish host interface during first boot.
BIOS must collect the new attribute values from BMC and update the same
in BIOS
BIOS must send the updated master attributes file to the BMC and once
its updated in BIOS
and reset the system to reflect the BIOS configuration.
OOB daemon in BMC must maintain and collect the attribute registry
file from MCTP/ IPMI/ Redfish interface.
Convert the proprietary XML format/ PLDM data into BIOS attribute
Registry format &
must support the below following dbus method.
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242
Validate the BIOS input data or User attribute value.
MCTP / Redfish host interface / IPMI must communicate with OOB daemon in
BMC via D bus
Thanks
Suryakanth.S
> ---------- Forwarded message ----------
> From: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com
> <mailto:dkodihal@linux.vnet.ibm.com>>
> Date: Feb 8, 2020 1:59 PM
> Subject: Exposing BIOS attributes to a remote management console
> To: openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
> Cc:
>
> Hi,
>
> To enable remote updates (via a remote management console that talks to
> the BMC) to the host firmware's BIOS settings table on IBM systems,
> we're thinking of the following flow:
>
> a) The host firmware sends down a BIOS settings table to the BMC using
> PLDM [1].
> b) The BMC uses phosphor-settingsd [2] as the backend to store BIOS
> attributes on D-Bus.
> c) Bmcweb implements the Redfish BIOS schema [3] to enable remote
> reads/writes on the BIOS attributes.
>
> However, c) is a problem because one needs to write YAML files [4] for
> the BMC to determine what D-Bus objects to make corresponding to the
> BIOS attributes. This requires a unique D-Bus interface *per* BIOS
> attribute. This means the BMC must have prior knowledge about the BIOS
> attributes.
>
> I don't think that's the right way to go about this for two reasons. One
> - this creates a lockstep dependency on the host firmware when the BIOS
> settings table needs to be updated, and two - I think the OpenBMC
> implementation of this must be able to receive (via PLDM/IPMI/other
> standard in-band means) a set of BIOS attributes from different BIOS
> firmware stacks dynamically and expose them for out of band updates,
> without having prior/build-time knowledge of those attributes. So I
> think this calls for a different kind of D-Bus interface/infrastructure
> than what the phosphor-settingsd app relies on. Something that enables
> the BMC to add to D-Bus a BIOS attribute dynamically, knowing it's name,
> type and default value.
>
> Any thoughts on this flow? I'm also curious to know if the Redfish BIOS
> schema/attribute registry model requires the BMC to have prior knowledge
> about the system BIOS attributes to update the registry. This wasn't
> obvious to me from a quick read of the schema.
>
> Thanks,
> Deepak
>
> [1]
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf
> [2] https://github.com/openbmc/phosphor-settingsd
> [3] https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json
> [4]
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/settings/phosphor-settings-defaults/defaults.yaml
>
[-- Attachment #2: Type: text/html, Size: 6798 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: FW: Exposing BIOS attributes to a remote management console
2020-02-10 10:49 ` FW: " Sekar, Suryakanth
@ 2020-02-11 8:52 ` Deepak Kodihalli
2020-02-18 9:55 ` Sekar, Suryakanth
0 siblings, 1 reply; 4+ messages in thread
From: Deepak Kodihalli @ 2020-02-11 8:52 UTC (permalink / raw)
To: Sekar, Suryakanth, openbmc, Thomaiyar, Richard Marian
On 10/02/20 4:19 pm, Sekar, Suryakanth wrote:
> Hi Deepak,
>
> OOB BIOS high level config design doc is in progress. I will send for
> review soon.
Hi Surya,
Thanks for responding. I'm glad that we have the same understanding on
this topic.
I'll look out for the design doc from you. Can you share now what
aspects that document would cover - redfish/in-band/D-Bus implementation
- all of this? Is Intel planning on writing code for these areas soon?
We're planning on implementing the PLDM BIOS spec for the same purpose.
Some PLDM BIOS code's out there on openbmc/pldm already.
> Yes, we need to support all interface -IPMI/ MCTP/ Redfish Host interface.
>
> If BIOS is not booted at all. BMC wont have any attribute info. It will
> be empty in BMC side.
>
> BIOS must provide BIOS OOB capability via KCS interface in early boot stage.
> Like supported proprietary BIOS attribute file format or PLDM support
> via MCTP or
> Redfish BIOS attribute registry format to the BMC.
>
> BIOS must send the master BIOS attributes file(Intel properitary - XML
> type 0)
> via KCS interface or all attributes details via Bios configuration PLDM
> via MCTP or
> Redfish host interface during first boot.
>
> BIOS must collect the new attribute values from BMC and update the same
> in BIOS
>
> BIOS must send the updated master attributes file to the BMC and once
> its updated in BIOS
>
> and reset the system to reflect the BIOS configuration.
>
> OOB daemon in BMC must maintain and collect the attribute registry
> file from MCTP/ IPMI/ Redfish interface.
All this sounds good to me.
> Convert the proprietary XML format/ PLDM data into BIOS attribute
> Registry format &
> must support the below following dbus method.
>
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242
>
> Validate the BIOS input data or User attribute value.
>
> MCTP / Redfish host interface / IPMI must communicate with OOB daemon in
> BMC via D bus
Are you targeting specific implementation areas here? By knowing that,
we can collaborate better.
> Thanks
>
> Suryakanth.S
Regards,
Deepak
>
>
>> ---------- Forwarded message ----------
>> From: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com
>> <mailto:dkodihal@linux.vnet.ibm.com>>
>> Date: Feb 8, 2020 1:59 PM
>> Subject: Exposing BIOS attributes to a remote management console
>> To: openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
>> Cc:
>>
>> Hi,
>>
>> To enable remote updates (via a remote management console that talks to
>> the BMC) to the host firmware's BIOS settings table on IBM systems,
>> we're thinking of the following flow:
>>
>> a) The host firmware sends down a BIOS settings table to the BMC using
>> PLDM [1].
>> b) The BMC uses phosphor-settingsd [2] as the backend to store BIOS
>> attributes on D-Bus.
>> c) Bmcweb implements the Redfish BIOS schema [3] to enable remote
>> reads/writes on the BIOS attributes.
>>
>> However, c) is a problem because one needs to write YAML files [4] for
>> the BMC to determine what D-Bus objects to make corresponding to the
>> BIOS attributes. This requires a unique D-Bus interface *per* BIOS
>> attribute. This means the BMC must have prior knowledge about the BIOS
>> attributes.
>>
>> I don't think that's the right way to go about this for two reasons. One
>> - this creates a lockstep dependency on the host firmware when the BIOS
>> settings table needs to be updated, and two - I think the OpenBMC
>> implementation of this must be able to receive (via PLDM/IPMI/other
>> standard in-band means) a set of BIOS attributes from different BIOS
>> firmware stacks dynamically and expose them for out of band updates,
>> without having prior/build-time knowledge of those attributes. So I
>> think this calls for a different kind of D-Bus interface/infrastructure
>> than what the phosphor-settingsd app relies on. Something that enables
>> the BMC to add to D-Bus a BIOS attribute dynamically, knowing it's name,
>> type and default value.
>>
>> Any thoughts on this flow? I'm also curious to know if the Redfish BIOS
>> schema/attribute registry model requires the BMC to have prior knowledge
>> about the system BIOS attributes to update the registry. This wasn't
>> obvious to me from a quick read of the schema.
>>
>> Thanks,
>> Deepak
>>
>> [1]
>> https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf
>> [2] https://github.com/openbmc/phosphor-settingsd
>> [3] https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json
>> [4]
>> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/settings/phosphor-settings-defaults/defaults.yaml
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: FW: Exposing BIOS attributes to a remote management console
2020-02-11 8:52 ` Deepak Kodihalli
@ 2020-02-18 9:55 ` Sekar, Suryakanth
0 siblings, 0 replies; 4+ messages in thread
From: Sekar, Suryakanth @ 2020-02-18 9:55 UTC (permalink / raw)
To: Deepak Kodihalli, openbmc, Thomaiyar, Richard Marian
Hi Deepak,
[Deepak]--> I'll look out for the design doc from you. Can you share
now what aspects that document would cover - redfish/in-band/D-Bus
implementation - all of this? Is Intel planning on writing code for
these areas soon? We're planning on implementing the PLDM BIOS spec for
the same purpose. Some PLDM BIOS code's out there on openbmc/pldm already.
Yes, we need to support all interface -IPMI/ MCTP/ Redfish Host interface.
[surya]--> Cover IPMI based implementation. we defined some OEM
commands under review.
https://gerrit.openbmc-project.xyz/c/openbmc/intel-ipmi-oem/+/16246
[Deepak]--> Are you targeting specific implementation areas here? By
knowing that, we can collaborate better.
[surya] -->We are working on IPMI command based in OOB daemon and
generating Attribute Registry for Redfish. you can implement the PLDM
based in OOB daemon and BIOS configuration WebGUI.
Please review the design and interface. Once its done. we will request
Brad to create separate recipe repository for OOB daemon.
Please let me know any query or concern.
Thanks
Suryakanth.S
On 2/11/2020 2:22 PM, Deepak Kodihalli wrote:
> On 10/02/20 4:19 pm, Sekar, Suryakanth wrote:
>> Hi Deepak,
>>
>> OOB BIOS high level config design doc is in progress. I will send for
>> review soon.
>
>
> Hi Surya,
>
> Thanks for responding. I'm glad that we have the same understanding on
> this topic.
>
> I'll look out for the design doc from you. Can you share now what
> aspects that document would cover - redfish/in-band/D-Bus
> implementation - all of this? Is Intel planning on writing code for
> these areas soon? We're planning on implementing the PLDM BIOS spec
> for the same purpose. Some PLDM BIOS code's out there on openbmc/pldm
> already.
>
>> Yes, we need to support all interface -IPMI/ MCTP/ Redfish Host
>> interface.
[surya]--> Cover IPMI based implementation. we defined some OEM
commands under review.
https://gerrit.openbmc-project.xyz/c/openbmc/intel-ipmi-oem/+/16246
>>
>> If BIOS is not booted at all. BMC wont have any attribute info. It
>> will be empty in BMC side.
>>
>> BIOS must provide BIOS OOB capability via KCS interface in early boot
>> stage.
>> Like supported proprietary BIOS attribute file format or PLDM support
>> via MCTP or
>> Redfish BIOS attribute registry format to the BMC.
>>
>> BIOS must send the master BIOS attributes file(Intel properitary -
>> XML type 0)
>> via KCS interface or all attributes details via Bios configuration
>> PLDM via MCTP or
>> Redfish host interface during first boot.
>>
>> BIOS must collect the new attribute values from BMC and update the
>> same in BIOS
>>
>> BIOS must send the updated master attributes file to the BMC and once
>> its updated in BIOS
>>
>> and reset the system to reflect the BIOS configuration.
>>
>> OOB daemon in BMC must maintain and collect the attribute registry
>> file from MCTP/ IPMI/ Redfish interface.
>
> All this sounds good to me.
>
>> Convert the proprietary XML format/ PLDM data into BIOS attribute
>> Registry format &
>> must support the below following dbus method.
>>
>> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/18242
>>
>>
>> Validate the BIOS input data or User attribute value.
>>
>> MCTP / Redfish host interface / IPMI must communicate with OOB daemon
>> in BMC via D bus
>
> Are you targeting specific implementation areas here? By knowing that,
> we can collaborate better.
[surya] -->We are working on IPMI command based in OOB daemon and
generating Attribute Registry for Redfish. you can implement the PLDM
based in OOB daemon and BIOS configuration WebGUI.
Please review the design and interface. Once its done. we will request
Brad to create separate recipe repository for OOB daemon.
Please let me know any query or concern.
>
>
>> Thanks
>>
>> Suryakanth.S
>
> Regards,
> Deepak
>
>>
>>
>>> ---------- Forwarded message ----------
>>> From: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com
>>> <mailto:dkodihal@linux.vnet.ibm.com>>
>>> Date: Feb 8, 2020 1:59 PM
>>> Subject: Exposing BIOS attributes to a remote management console
>>> To: openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
>>> Cc:
>>>
>>> Hi,
>>>
>>> To enable remote updates (via a remote management console that talks to
>>> the BMC) to the host firmware's BIOS settings table on IBM systems,
>>> we're thinking of the following flow:
>>>
>>> a) The host firmware sends down a BIOS settings table to the BMC using
>>> PLDM [1].
>>> b) The BMC uses phosphor-settingsd [2] as the backend to store BIOS
>>> attributes on D-Bus.
>>> c) Bmcweb implements the Redfish BIOS schema [3] to enable remote
>>> reads/writes on the BIOS attributes.
>>>
>>> However, c) is a problem because one needs to write YAML files [4] for
>>> the BMC to determine what D-Bus objects to make corresponding to the
>>> BIOS attributes. This requires a unique D-Bus interface *per* BIOS
>>> attribute. This means the BMC must have prior knowledge about the BIOS
>>> attributes.
>>>
>>> I don't think that's the right way to go about this for two reasons.
>>> One
>>> - this creates a lockstep dependency on the host firmware when the BIOS
>>> settings table needs to be updated, and two - I think the OpenBMC
>>> implementation of this must be able to receive (via PLDM/IPMI/other
>>> standard in-band means) a set of BIOS attributes from different BIOS
>>> firmware stacks dynamically and expose them for out of band updates,
>>> without having prior/build-time knowledge of those attributes. So I
>>> think this calls for a different kind of D-Bus interface/infrastructure
>>> than what the phosphor-settingsd app relies on. Something that enables
>>> the BMC to add to D-Bus a BIOS attribute dynamically, knowing it's
>>> name,
>>> type and default value.
>>>
>>> Any thoughts on this flow? I'm also curious to know if the Redfish BIOS
>>> schema/attribute registry model requires the BMC to have prior
>>> knowledge
>>> about the system BIOS attributes to update the registry. This wasn't
>>> obvious to me from a quick read of the schema.
>>>
>>> Thanks,
>>> Deepak
>>>
>>> [1]
>>> https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf
>>>
>>> [2] https://github.com/openbmc/phosphor-settingsd
>>> [3] https://redfish.dmtf.org/schemas/v1/Bios.v1_1_0.json
>>> [4]
>>> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/settings/phosphor-settings-defaults/defaults.yaml
>>>
>>>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-02-18 9:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-08 8:28 Exposing BIOS attributes to a remote management console Deepak Kodihalli
[not found] ` <48777ea3-0af2-4725-9304-64ae4edb71d9@email.android.com>
[not found] ` <1504A9E7C77EF44697F386AD61B16260152FEBA5@BGSMSX105.gar.corp.intel.com>
2020-02-10 10:49 ` FW: " Sekar, Suryakanth
2020-02-11 8:52 ` Deepak Kodihalli
2020-02-18 9:55 ` Sekar, Suryakanth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.