<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Ratan / Manoj, <br>
</p>
<p>Hypervisor (VM) Ethernet Interfaces is not a BIOS / Host firmware
settings right?. Is there any model, where the BIOS Settings of
Host Network interface like IPV4 / IPV6 is passed to the OS level
(If yes, through what mechanism, proprietary ?). We have BIOS
Network settings, but mostly that will be used in terms of PXE
boot etc., but this will not be passed to the Host OS/ Hypervisor
(which has to manage this on it's own). Let me know if i am
missing anything here. So not sure, why Hypervisor / OS Ethernet
interface must be passed to BIOS Settings instead of directly
communicating to the Hypervisor / OS level software directly.<br>
</p>
<p>For BIOS settings --> Pending v/s configured value, <a
moz-do-not-send="true"
href="https://github.com/openbmc/docs/blob/master/designs/remote-bios-configuration.md">Remote
BIOS configuration design doc</a>, already handles the same
using PendingAttributes. This is based on the AttributeRegistry
and as per the design it don't advertise every single setting in
D-Bus, instead it will be collection (dynamic in nature). <br>
</p>
<p>For Hypervisor / System Ethernet Interfaces I agree with James F,
As long as bmcweb does the mapper query and / or association to
determine the Service and Object path of the daemon, which will
handle the ComputerSystem (Host) EthernetInterfaces it should be
fine as the mechanism of forwarding the data to the OS will be
different based on implementation.<br>
</p>
<p>Regards,</p>
<p>Richard</p>
<div class="moz-cite-prefix">On 9/17/2020 1:10 PM, Ratan Gupta
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a5f0245d-703d-e0ba-0344-442c49a60cdf@linux.vnet.ibm.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<tt>Hi Pattrick, Ed,</tt><tt><br>
</tt><tt><br>
</tt><tt><br>
</tt><tt>We need to address the below two concerns with the
existing settings infra.</tt>
<ul>
<li><tt>Pending v/s configured value: Currently settings have
single Dbus Object, </tt><tt><tt> Some properties which is
for host firmware we need to have </tt><tt>two
placeholders one </tt>for Pending values and one for
Configured values. </tt><tt>Bios settings have this
concept.<br>
</tt></li>
<ul>
<li><tt>Should we add two Dbus objects in settings infra?</tt><tt><br>
</tt></li>
</ul>
<li><tt>Dynamic Dbus objects: Currently settings infrastructure
is only for static objects, Objects which gets added on
runtime, settings infra doesn't support that.</tt></li>
<ul>
<li><tt>Eg: IP address on ethernet interface is dynamic in
nature, An ethernet interface can have multiple IP address
on it. considering if SLAAC is enabled(ipV6).</tt></li>
<li><tt>Seems this problem is common for both(settings v/s
bios-settings)</tt><tt><br>
</tt></li>
</ul>
</ul>
<tt>Regards</tt><tt><br>
</tt><tt>Ratan Gupta</tt><br>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/16/20 11:14 PM, Ed Tanous wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACWQX80BYYwPTN1PsbLfjFN5fQyjNGC1SxM9iyBKvxNiLh=WLQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Wed, Sep 16, 2020 at 10:20 AM Patrick Williams <a class="moz-txt-link-rfc2396E" href="mailto:patrick@stwcx.xyz" moz-do-not-send="true"><patrick@stwcx.xyz></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Wed, Sep 16, 2020 at 08:17:01PM +0530, manoj kiran wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Ed & James,
Till now IBM was using phosphor-settings infrastructure as back-end and uses Ethernet Schema for Hypervisor computer system(hypervisor_ethernet.hpp) for setting the IP address of hypervisor. And now we are planning to leverage the capabilities of bios-settings-mgr(backend) as well to set the hypervisor attributes.
do you see any concerns here ?
Thanks,
Manoj
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">These end up being two quite different implementations from a dbus
perspective, which could have implications to Redfish and webui users.
With 'settings' there is no generic settings interfacess on dbus; every
setting is required to have some modeled interface. This is great when
you are exposing some hypervisor setting that the BMC also has for
itself, such as network. We have a single dbus interface for all
network end-points and it doesn't matter if it is for the BMC or the
Hypervisor.
With 'bios-settings-mgr' there are only generic free-form settings
values, which presently can be either int64 or string[1].
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">If this is correct, then I withdraw my support. I had assumed
bios-settings-mgr would host several objects that contain an
EthernetInterface [1] api, similar to what phosphor-networkd does, and
whose endpoints require no new code in most of the endpoints. If
we're talking about moving all this to a simple key-value store,
running on yet another representation of what a network interface
looks like, that's going in the wrong direction in terms of fidelity
and complexity.
With that said, if I'm mistaken, let me know.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> This means
there is no overlap with any similar settings we have on the BMC and
there is no programatic way to ensure the data is of the right type and
named with the right key. This approach is better when you have large
numbers of attributes for concepts which the BMC doesn't have itself.
My understanding was that the 'bios-settings-mgr' was typically going to be
used for uploading a large blob of configuration values and the external
interfaces would have fairly minimal code related to individual
settings. My concern with using 'bios-settings-mgr' in general is that
it will end up being very tight coupling between external interfaces
(Redfish / webui) and BIOS implementations. When you use 'settings',
you can implement much more generic external interface code and likely
limit the coupling, if any, to the PLDM provider.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think we have one benefit here in that there's going to be several
implementations of the bios-settings-mgr for the various bios
implementations that will keep us more "honest" about our APIs. It's
not a satisfying answer, I realize, but I think it's the best we can
do at the moment.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Net is, if you're expecting to be able to modify hypervisor values
through Redfish or WebUI, I think the best approach is to use
'settings'.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">The problem with the "settings" approach becomes error handling.
Settingsd has no context of a transaction, or a backend on the other
side, so when and if things fail, they fail silently, or possibly with
a log. In the case of hosting this API in the BIOS daemon, it can
actually do the "commit" of the parameters to BIOS as part of the dbus
transaction, so once the return code is received from the method call,
the user can know that the values were "latched", and can knowingly
move on. If they weren't latched, the client can know if it makes
sense to retry, or do some other procedure.
This also has nice properties for the BMC, as it never has to "own"
storage of the data, nor does it have to implement all the validation
routines, as it can rely on the actual data owner to do so.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">1. <a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/77a742627edde54aec625d7c1a200d9f4832f0ba/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml#L44" moz-do-not-send="true">https://github.com/openbmc/phosphor-dbus-interfaces/blob/77a742627edde54aec625d7c1a200d9f4832f0ba/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml#L44</a>
--
Patrick Williams
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">1. <a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Network/EthernetInterface.interface.yaml" moz-do-not-send="true">https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Network/EthernetInterface.interface.yaml</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>