Multi-host support in ipmbbridged and phosphor-host-ipmid

[Vernon Mauery]

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.

>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.

>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,

>      "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.).

>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.

--Vernon