Multi-host support in ipmbbridged and phosphor-host-ipmid
Velumani T-ERS,HCLTech
velumanit at hcl.com
Wed Jul 8 21:20:52 AEST 2020
Hi Vernon,
Thanks for your comments. Please find my response inline. As suggested by Andrew I have moved the design doc to gerrit. We will use the same going forward. Kindly provide your comments in gerrit.
Gerrit link: https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/34464
Regards,
Velu
-----Original Message-----
From: Vernon Mauery <vernon.mauery at linux.intel.com>
Sent: Tuesday, July 7, 2020 2:50 AM
To: Velumani T-ERS,HCLTech <velumanit at hcl.com>
Cc: openbmc at lists.ozlabs.org; Dawid Frycki <dawid.frycki at intel.com>; Ed Tanous <ed.tanous at intel.com>; Adriana Kobylak <anoo at us.ibm.com>; Patrick Williams <patrickw3 at fb.com>; Kumar Thangavel <thangavel.k at hcl.com>; Vijay Khemka <vijaykhemka at fb.com>; Ratan Gupta <ratagupt at linux.vnet.ibm.com>
Subject: Re: Multi-host support in ipmbbridged and phosphor-host-ipmid
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
On 03-Jul-2020 05:22 PM, Velumani T-ERS,HCLTech wrote:
>Hi All,
>
>We have a multi-host system and wanted to add support in openbmc to handle all ipmi commands. We have come up with the design approach that could help us in handling ipmi command with multihost system. Please find the attached design proposal and provide feedback/suggestions.
>
>Regards,
>Velu
>
>::DISCLAIMER::
>________________________________
>The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
>________________________________
>
>
># Multi-host IPMI design
>------------------------
>
>Authors:
> Velumani T, [velumanit at hcl](mailto:velumanit at hcl.com)
> Kumar T, [thangavel.k at hcl.com](mailto:thangavel.k at hcl.com)
>
>Primary assignee:
>
>Other contributors:
>
>Created:
> 2020-06-26
>
>1. Issue Descriptionption:
>--------------------
>The current version of openbmc does not support multi-host
>implementation in ipmi commands handling. We have a multi-host system
>and proposing the design to support multi-host.
>
>As detailed below the hosts are connected in the ipmb interface, all
>host related communication is based on ipmb. The openbmc uses
>ipmbbridged to manage ipmb busses and the ipmb messages are routed to ipmid.
>
>Issue 1: ipmbridged does not support more than 2 channels
ipmbbridged should support as many channels as are specified in the configuration file. A change like this would go in your bbappend in your platform layer.
[Velu] Yes. We will use the config file for adding the more channel. Currently this is not working and debugging the same. But we have updated the design document with your comments.
>Issue 2: ipmid does not have the information on which ipmb channel the
>request has come from. The ipmid handlers should have the host details
>to fetch the host specific responses.
It has enough information to map it to an IPMI channel and to send it back to the requester.
[Velu] Yes, we plan to use the parameter "options"
>2. IPMI and IPMB System architecture:
>--------------------------------------
> +-----------+ +------------+ +--------+
> | | | | ipmb1| |
> | | | |------| Host-1 |
> | | | | | |
> | | | | +--------+
> | | | |
> | | | |
> | | dbus | | +--------+
> | ipmid |-------| Ipmbbridged| ipmb2| |
> | | | |------| Host-2 |
> | | | | | |
> | | | | +--------+
> | | | |
> | | | |
> | | | | +--------+
> | | | | ipmb | |
> | | | |------| Host-N |
> | | | | | |
> +-----------+ +------------+ +--------+
>
>Hosts are connected with ipmb interface, the hosts can be 1 to N. The
>ipmb request coming from the hosts are routed to ipmid by the ipmbbridged.
>The ipmd requests are routed from ipmid or any service by d-bus
>interface and the ipmbbridged routes to ipmb interface.
>
>3. Proposed Design:
>--------------------
>To address issue1 and issue2, we propose the following design changes
>in ipmbbridged and ipmid.
>
>3.1 Changes in ipmbbridged:
>---------------------------
>The current ipmbbridged supports only 2 channels and this needs to be
>enhanced to more channels.
>ipmbbridged to send the channel details from where the request is
>received
>
>3.1.1 Change1 : support more than 2 channels
>---------------------------------------------
>To support more than 2 channels, we propose to add additional channels
>named "host1", "host2" ..."hostn"
>
>This can be decided by the config file "ipmb-channels.json", The change
>will look like below
>
>{
> "channels": [
> {
> "type": "me",
> "slave-path": "/dev/ipmb-1",
> "bmc-addr": 32,
> "remote-addr": 44
> },
> {
> "type": "ipmb",
> "slave-path": "/dev/ipmb-2",
> "bmc-addr": 32,
> "remote-addr": 96
> }
> {
> "type": "host1",
I don't understand why you need to have a new type here. Each of these channels are IPMB channels (according to the IPMI specification)
You do need somewhere to mark the ID of the host, but I feel that would be better suited as a new entry
"host": 1,
[Velu] Agreed, we will use a new entry as suggested. Updated the design document.
> "slave-path": "/dev/ipmb-3",
> "bmc-addr": 32,
> "remote-addr": 64
> }
> {
> "type": "host2",
> "slave-path": "/dev/ipmb-4",
> "bmc-addr": 32,
> "remote-addr": 64
> }
> {
> "type": "host3",
> "slave-path": "/dev/ipmb-4",
> "bmc-addr": 32,
> "remote-addr": 64
> }
> ]
>}
>
>Reading the json file ipmbbridged to support host channels optionally.
>
>3.1.2. Change 2: Sending Host detail as addional parameter
>-----------------------------------------------------------
>While routing the ipmb requests coming from the host channel, the
>ipmbbridged adds the ipmb bus details configured in the json file key "type".
>In the above example the ipmb request coming from "/dev/ipmb-4" the
>ipmb will send "host2" as optional parameter in the d-bus interface to ipmid.
Better would be a host:2 entry
>3.2 Changes in ipmid:
>---------------------
>Receive the optional parameter sent by the ipmbbriged as host details,
>while receiving the parameter in the executionEntry method call the
>same will be passed to the command handlers in both common and oem handlers.
>The command handlers can make use of the host information to fetch host
>specific data.
I would suggest that this is a new item in the ipmi::Context class. It should default to 0 (first host), and can be set by by a bridge (ipmbbridged, kcsbridged, etc.).
[Velu] OK. We will use ipmi::Context class.
>For example, host1 send a request to get boot order from bmc, bmc
>maintains data separately for each host. When this command comes to
>ipmid the commands handler gets the host in which the command received.
>The handler will fetch
>host1 boot order details and respond from the command handler. This is
>applicable for both common and oem handlers.
It would be up to the handler to behave correctly by checking the ipmi::Context.
[Velu] OK.
--Vernon
More information about the openbmc
mailing list