<div dir="ltr">Hi Jeremy,<div><br></div><div>I had a couple comments on the initial draft.</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 7, 2018 at 9:09 AM Supreeth Venkatesh <<a href="mailto:supreeth.venkatesh@arm.com">supreeth.venkatesh@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2018-12-07 at 10:43 +0530, Deepak Kodihalli wrote:<br>
> On 07/12/18 8:11 AM, Jeremy Kerr wrote:<br>
> > Hi OpenBMCers!<br>
> > <br>
> > In an earlier thread, I promised to sketch out a design for a MCTP<br>
> > implementation in OpenBMC, and I've included it below.<br>
> <br>
> <br>
> Thanks Jeremy for sending this out. This looks good (have just one <br>
> comment below).<br>
> <br>
> Question for everyone : do you have plans to employ PLDM over MCTP?<br>
Yes Deepak. we do eventually.<br>
<br>
> <br>
> We are interested in PLDM for various "inside the box"<br>
> communications <br>
> (at the moment for the Host <-> BMC communication). I'd like to<br>
> propose <br>
> a design for a PLDM stack on OpenBMC, and would send a design<br>
> template <br>
> for review on the mailing list in some amount of time (I've just<br>
> started <br>
> with some initial sketches). I'd like to also know if others have <br>
> embarked on a similar activity, so that we can collaborate earlier<br>
> and <br>
> avoid duplicate work.<br>
Yes. Interested to collaborate.<br>
Which portion of PLDM are you working on, other than base?<br>
Platform Monitoring and Control?<br>
Firmware Update?<br>
BIOS Control andConfiguration?<br>
SMBIOS Transfer?<br>
FRU Data?<br>
Redfish Device Enablement?<br>
<br>
We are currently interested in Platform Monitoring and Control.<br>
<br>
<br>
> <br>
> > This is roughly in the OpenBMC design document format (thanks for<br>
> > the<br>
> > reminder Andrew), but I've sent it to the list for initial review<br>
> > before<br>
> > proposing to gerrit - mainly because there were a lot of folks who<br>
> > expressed interest on the list. I suggest we move to gerrit once we<br>
> > get<br>
> > specific feedback coming in. Let me know if you have general<br>
> > comments<br>
> > whenever you like though.<br>
> > <br>
> > In parallel, I've been developing a prototype for the MCTP library<br>
> > mentioned below, including a serial transport binding. I'll push to<br>
> > github soon and post a link, once I have it in a<br>
> > slightly-more-consumable form.<br>
> > <br>
> > Cheers,<br>
> > <br>
> > <br>
> > Jeremy<br>
> > <br>
> > --------------------------------------------------------<br>
> > <br>
> > # Host/BMC communication channel: MCTP & PLDM<br>
> > <br>
> > Author: Jeremy Kerr <<a href="mailto:jk@ozlabs.org" target="_blank">jk@ozlabs.org</a>> <jk><br>
> > <br>
> > ## Problem Description<br>
> > <br>
> > Currently, we have a few different methods of communication between<br>
> > host<br>
> > and BMC. This is primarily IPMI-based, but also includes a few<br>
> > hardware-specific side-channels, like hiomap. On OpenPOWER hardware<br>
> > at<br>
> > least, we've definitely started to hit some of the limitations of<br>
> > IPMI<br>
> > (for example, we have need for >255 sensors), as well as the<br>
> > hardware<br>
> > channels that IPMI typically uses.<br>
> > <br>
> > This design aims to use the Management Component Transport Protocol<br>
> > (MCTP) to provide a common transport layer over the multiple<br>
> > channels<br>
> > that OpenBMC platforms provide. Then, on top of MCTP, we have the<br>
> > opportunity to move to newer host/BMC messaging protocols to<br>
> > overcome<br>
> > some of the limitations we've encountered with IPMI.<br>
> > <br>
> > ## Background and References<br>
> > <br>
> > Separating the "transport" and "messaging protocol" parts of the<br>
> > current<br>
> > stack allows us to design these parts separately. Currently, IPMI<br>
> > defines both of these; we currently have BT and KCS (both defined<br>
> > as<br>
> > part of the IPMI 2.0 standard) as the transports, and IPMI itself<br>
> > as the<br>
> > messaging protocol.<br>
> > <br>
> > Some efforts of improving the hardware transport mechanism of IPMI<br>
> > have<br>
> > been attempted, but not in a cross-implementation manner so far.<br>
> > This<br>
> > does not address some of the limitations of the IPMI data model.<br>
> > <br>
> > MCTP defines a standard transport protocol, plus a number of<br>
> > separate<br>
> > hardware bindings for the actual transport of MCTP packets. These<br>
> > are<br>
> > defined by the DMTF's Platform Management Working group; standards<br>
> > are<br>
> > available at:<br>
> > <br>
> >    <a href="https://www.dmtf.org/standards/pmci" rel="noreferrer" target="_blank">https://www.dmtf.org/standards/pmci</a><br>
> > <br>
> > I have included a small diagram of how these standards may fit<br>
> > together<br>
> > in an OpenBMC system. The DSP numbers there are references to DMTF<br>
> > standards.<br>
> > <br>
> > One of the key concepts here is that separation of transport<br>
> > protocol<br>
> > from the hardware bindings; this means that an MCTP "stack" may be<br>
> > using<br>
> > either a I2C, PCI, Serial or custom hardware channel, without the<br>
> > higher<br>
> > layers of that stack needing to be aware of the hardware<br>
> > implementation.<br>
> > These higher levels only need to be aware that they are<br>
> > communicating<br>
> > with a certain entity, defined by an Entity ID (MCTP EID).<br>
> > <br>
> > I've mainly focussed on the "transport" part of the design here.<br>
> > While<br>
> > this does enable new messaging protocols (mainly PLDM), I haven't<br>
> > covered that much; we will propose those details for a separate<br>
> > design<br>
> > effort.<br>
> > <br>
> > As part of the design, I have referred to MCTP "messages" and<br>
> > "packets";<br>
> > this is intentional, to match the definitions in the MCTP standard.<br>
> > MCTP<br>
> > messages are the higher-level data transferred between MCTP<br>
> > endpoints,<br>
> > which packets are typically smaller, and are what is sent over the<br>
> > hardware. Messages that are larger than the hardware MTU are split<br>
> > into<br>
> > individual packets by the transmit implementation, and reassembled<br>
> > at<br>
> > the receive implementation.<br>
> > <br>
> > A final important point is that this design is for the host <--><br>
> > BMC<br>
> > channel *only*. Even if we do replace IPMI for the host interface,<br>
> > we<br>
> > will certainly need an IPMI interface available for external system<br>
> > management.<br></blockquote><div><br></div><div>I'm not sure it's correct to demand external IPMI. Most of OpenBMC community (ourselves excluded :( ) is turning towards Redfish for this role.  The external-facing IPMI specification is insecure at the standard level, so I don't think that we should be encouraging or requiring it anywhere, even in an unrelated doc.</div><div>tl;dr I think you should be more generic here and not specify IPMI for external mgmt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > <br>
> > ## Requirements<br>
> > <br>
> > Any channel between host and BMC should:<br>
> > <br>
> >   - Have a simple serialisation and deserialisation format, to<br>
> > enable<br>
> >     implementations in host firmware, which have widely varying<br>
> > runtime<br>
> >     capabilities<br>
> > <br>
> >   - Allow different hardware channels, as we have a wide variety of<br>
> >     target platforms for OpenBMC<br>
> > <br>
> >   - Be usable over simple hardware implementations, but have a<br>
> > facility<br>
> >     for higher bandwidth messaging on platforms that require it.<br>
> > <br>
> >   - Ideally, integrate with newer messaging protocols<br>
> > <br>
> > ## Proposed Design<br>
> > <br>
> > The MCTP core specification just provides the packetisation,<br>
> > routing and<br>
> > addressing mechanisms. The actual transmit/receive of those packets<br>
> > is<br>
> > up to the hardware binding of the MCTP transport.<br>
> > <br>
> > For OpenBMC, we would introduce an MCTP daemon, which implements<br>
> > the<br>
> > transport over a configurable hardware channel (eg., Serial UART,<br>
> > I2C or<br>
> > PCI). This daemon is responsible for the packetisation and routing<br>
> > of<br>
> > MCTP messages to and from host firmware.<br>
> > <br>
> > I see two options for the "inbound" or "application" interface of<br>
> > the<br>
> > MCTP daemon:<br>
> > <br>
> >   - it could handle upper parts of the stack (eg PLDM) directly,<br>
> > through<br>
> >     in-process handlers that register for certain MCTP message<br>
> > types; or<br>
> <br>
> We'd like to somehow ensure (at least via documentation) that the <br>
> handlers don't block the MCTP daemon from processing incoming<br>
> traffic. <br>
> The handlers might anyway end up making IPC calls (via D-Bus) to<br>
> other <br>
> processes. The second approach below seems to alleviate this problem.<br>
> <br>
> >   - it could channel raw MCTP messages (reassembled from MCTP<br>
> > packets) to<br>
> >     DBUS messages (similar to the current IPMI host daemons), where<br>
> > the<br>
> >     upper layers receive and act on those DBUS events.<br>
> > <br>
> > I have a preference for the former, but I would be interested to<br>
> > hear<br>
> > from the IPMI folks about how the latter structure has worked in<br>
> > the<br>
> > past.<br>
> > <br>
> > The proposed implementation here is to produce an MCTP "library"<br>
> > which<br>
> > provides the packetisation and routing functions, between:<br>
> > <br>
> >   - an "upper" messaging transmit/receive interface, for tx/rx of a<br>
> > full<br>
> >     message to a specific endpoint<br>
> > <br>
> >   - a "lower" hardware binding for transmit/receive of individual<br>
> >     packets, providing a method for the core to tx/rx each packet<br>
> > to<br>
> >     hardware<br>
> > <br>
> > The lower interface would be plugged in to one of a number of<br>
> > hardware-specific binding implementations (most of which would be<br>
> > included in the library source tree, but others can be plugged-in<br>
> > too)<br>
> > <br>
> > The reason for a library is to allow the same MCTP implementation<br>
> > to be<br>
> > used in both OpenBMC and host firmware; the library should be<br>
> > bidirectional. To allow this, the library would be written in<br>
> > portable C<br>
> > (structured in a way that can be compiled as "extern C" in C++<br>
> > codebases), and be able to be configured to suit those runtime<br>
> > environments (for example, POSIX IO may not be available on all<br>
> > platforms; we should be able to compile the library to suit). The<br>
> > licence for the library should also allow this re-use; I'd suggest<br>
> > a<br>
> > dual Apache & GPL licence.<br></blockquote><div><br></div><div>Love the idea of the implementation being bidirectional and able to be dropped onto the host side as well, but I must be missing why that requires we write it in C.  Are we targeting some platform missing a C++ cross-compiler implementation? If we're implementing something new from scratch, I'd so much prefer to bump up the maintainability/modernity and write it in C++ if we can.  Or could be I'm missing some key reason that it follows we use C :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > <br>
> > As for the hardware bindings, we would want to implement a serial<br>
> > transport binding first, to allow easy prototyping in simulation.<br>
> > For<br>
> > OpenPOWER, we'd want to implement a "raw LPC" binding for better<br>
> > performance, and later PCIe for large transfers. I imagine that<br>
> > there is<br>
> > a need for an I2C binding implementation for other hardware<br>
> > platforms<br>
> > too.<br>
> > <br>
> > Lastly, I don't want to exclude any currently-used interfaces by<br>
> > implementing MCTP - this should be an optional component of<br>
> > OpenBMC, and<br>
> > not require platforms to implement it.<br>
> > <br>
> > ## Alternatives Considered<br>
> > <br>
> > There have been two main alternatives to this approach:<br>
> > <br>
> > Continue using IPMI, but start making more use of OEM extensions to<br>
> > suit the requirements of new platforms. However, given that the<br>
> > IPMI<br>
> > standard is no longer under active development, we would likely end<br>
> > up<br>
> > with a large amount of platform-specific customisations. This also<br>
> > does<br>
> > not solve the hardware channel issues in a standard manner.<br>
> > <br>
> > Redfish between host and BMC. This would mean that host firmware<br>
> > needs a<br>
> > HTTP client, a TCP/IP stack, a JSON (de)serialiser, and support for<br>
> > Redfish schema. This is not feasible for all host firmware<br>
> > implementations; certainly not for OpenPOWER. It's possible that we<br>
> > could run a simplified Redfish stack - indeed, MCTP has a proposal<br>
> > for a<br>
> > Redfish-over-MCTP protocol, which uses simplified serialisation and<br>
> > no<br>
> > requirement on HTTP. However, this still introduces a large amount<br>
> > of<br>
> > complexity in host firmware.<br>
> > <br>
> > ## Impacts<br>
> > <br>
> > Development would be required to implement the MCTP transport, plus<br>
> > any<br>
> > new users of the MCTP messaging (eg, a PLDM implementation). These<br>
> > would<br>
> > somewhat duplicate the work we have in IPMI handlers.<br>
> > <br>
> > We'd want to keep IPMI running in parallel, so the "upgrade" path<br>
> > should<br>
> > be fairly straightforward.<br>
> > <br>
> > Design and development needs to involve potential host firmware<br>
> > implementations.<br>
> > <br>
> > ## Testing<br>
> > <br>
> > For the core MCTP library, we are able to run tests there in<br>
> > complete<br>
> > isolation (I have already been able to run a prototype MCTP stack<br>
> > through the afl fuzzer) to ensure that the core transport protocol<br>
> > works.<br>
> > <br>
> > For MCTP hardware bindings, we would develop channel-specific tests<br>
> > that<br>
> > would be run in CI on both host and BMC.<br>
> > <br>
> > For the OpenBMC MCTP daemon implementation, testing models would<br>
> > depend<br>
> > on the structure we adopt in the design section.<br>
> > <br>
> <br>
> Regards,<br>
> Deepak<br>
> <br>
<br>
</blockquote></div></div>