Storing host data on the BMC

[Deepak Kodihalli]

On 14/05/20 2:48 am, Patrick Williams wrote:
> On Wed, May 13, 2020 at 08:37:32PM +0530, Sunitha Harish wrote:
>> My scenario is :
>> 1. Redfish client sets the host interface parameters for the IPv4
>> address. These user settable values are stored in the DBus.
> 
> Ignoring which process "stores" this data, we have two mechanisms over
> DBus to store this kind of data.  I can't tell fully from your
> explaination which is more appropriate for this data.
> 
> 1. Data we want to split out into well-formed, existing dbus objects.
> 
>      * We already have interfaces to store networking information under
>        xyz/openbmc_project/Network.
> 
> 2. Data which is generic / opaque to the BMC and we're just using the
>     BMC as a "storage location".
> 
>     * This would be the proposed BIOS attributes interface.
> 
> So the question to you is, do you want the BMC to actively interact with
> and manage this data, like we do for our own data, or do you want the
> BMC to just be a dumb passthru of this data?
> 
>> 2. When the system is powered on , the pldm reads these DBus values ,
>> and sets the BIOS attributes.
>> 3. The hypervisor reads this BIOS attributes for the interfaces and sets
>> them.
> 
> It doesn't seem like two steps matter with respect to the 1/2 above.
> Where the data is obtained in this regard can be self-contained in your
> PLDM provider, correct?
> 
>> 4. Now the hypervisor sends an indication to the pldm that the IP
>> address is active at its interface and its Origin is Static ( ie : user
>> configured) OR it is DHCP ( ie: not user configured, if its DHCP enabled)
>> 5. The pldm should store this Origin value "somewhere".
> 
> This description makes it seem like you want it to be more "managed"
> data than "opaque", if I'm reading this correctly.
> 
>> Redfish client would need this value to interpret where the IP address
>> has been Originated from. So we need a DBus property to save it. But ,
>> this is actually an attribute which is set by the hypervisor/host - a
>> pldm sensor. Its not suitable to be fit into the BIOS table. My
>> question&proposal is about how/where to store this value?
> 
> I think we need to be careful about being hung up on the name "BIOS
> table".  For opaque data that is more OS-centric,  we could  make the
> proposed "BIOS Attributes" interface more generic to store different
> levels of host-owned data: BIOS, Hypervisor, OS.  This might be a good
> comment to make on the interface code review.

I think the current proposal from Surya enables this already. Do you 
just mean the design doc should explicitly state this isn't restricted 
to the "BIOS" firmware.

As far as Sunitha's question goes, my point is that not all host 
firmware generated data is a BIOS attribute. For eg if the host tells me 
about the presence of certain FRUs, or their functional states, I 
wouldn't want to store those in the BIOS attributes backend, I'd rather 
associates those with the existing D-Bus interfaces for the FRU 
inventory. I think the same applies to the Origin property that has been 
described - associate with the networking D-Bus backend.

> If you are wanting the data to be managed, utilizing existing DBus
> interfaces we have around networking, doesn't phosphor-settingsd cover
> that from an implementation perspective?

I don't think the 'Origin' property is a setting.

Regards,
Deepak