1d070b7d7SDeepak Kodihalli# PLDM stack on OpenBMC 2d070b7d7SDeepak Kodihalli 3d070b7d7SDeepak KodihalliAuthor: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com> <dkodihal> 44134f4f1SDeepak Kodihalli 5d070b7d7SDeepak KodihalliCreated: 2019-01-22 6d070b7d7SDeepak Kodihalli 7d070b7d7SDeepak Kodihalli## Problem Description 8*f4febd00SPatrick Williams 9d070b7d7SDeepak KodihalliOn OpenBMC, in-band IPMI is currently the primary industry-standard means of 10d070b7d7SDeepak Kodihallicommunication between the BMC and the Host firmware. We've started hitting some 11d070b7d7SDeepak Kodihalliinherent limitations of IPMI on OpenPOWER servers: a limited number of sensors, 12d070b7d7SDeepak Kodihalliand a lack of a generic control mechanism (sensors are a generic monitoring 13d070b7d7SDeepak Kodihallimechanism) are the major ones. There is a need to improve upon the communication 14d070b7d7SDeepak Kodihalliprotocol, but at the same time inventing a custom protocol is undesirable. 15d070b7d7SDeepak Kodihalli 16d070b7d7SDeepak KodihalliThis design aims to employ Platform Level Data Model (PLDM), a standard 17d070b7d7SDeepak Kodihalliapplication layer communication protocol defined by the DMTF. PLDM draws inputs 18d070b7d7SDeepak Kodihallifrom IPMI, but it overcomes most of the latter's limitations. PLDM is also 19d070b7d7SDeepak Kodihallidesigned to run on standard transport protocols, for e.g. MCTP (also designed by 20d070b7d7SDeepak Kodihallithe DMTF). MCTP provides for a common transport layer over several physical 21d070b7d7SDeepak Kodihallichannels, by defining hardware bindings. The solution of PLDM over MCTP also 22d070b7d7SDeepak Kodihallihelps overcome some of the limitations of the hardware channels that IPMI uses. 23d070b7d7SDeepak Kodihalli 24d070b7d7SDeepak KodihalliPLDM's purpose is to enable all sorts of "inside the box communication": BMC - 25d070b7d7SDeepak KodihalliHost, BMC - BMC, BMC - Network Controller and BMC - Other (for e.g. sensor) 26d070b7d7SDeepak Kodihallidevices. 27d070b7d7SDeepak Kodihalli 28d070b7d7SDeepak Kodihalli## Background and References 29*f4febd00SPatrick Williams 30d070b7d7SDeepak KodihalliPLDM is designed to be an effective interface and data model that provides 31d070b7d7SDeepak Kodihalliefficient access to low-level platform inventory, monitoring, control, event, 32d070b7d7SDeepak Kodihalliand data/parameters transfer functions. For example, temperature, voltage, or 33d070b7d7SDeepak Kodihallifan sensors can have a PLDM representation that can be used to monitor and 34d070b7d7SDeepak Kodihallicontrol the platform using a set of PLDM messages. PLDM defines data 35d070b7d7SDeepak Kodihallirepresentations and commands that abstract the platform management hardware. 36d070b7d7SDeepak Kodihalli 37*f4febd00SPatrick WilliamsPLDM groups commands under broader functions, and defines separate 38*f4febd00SPatrick Williamsspecifications for each of these functions (also called PLDM "Types"). The 39*f4febd00SPatrick Williamscurrently defined Types (and corresponding specs) are : PLDM base (with 40d070b7d7SDeepak Kodihalliassociated IDs and states specs), BIOS, FRU, Platform monitoring and control, 41d070b7d7SDeepak KodihalliFirmware Update and SMBIOS. All these specifications are available at: 42d070b7d7SDeepak Kodihalli 43d070b7d7SDeepak Kodihallihttps://www.dmtf.org/standards/pmci 44d070b7d7SDeepak Kodihalli 45d070b7d7SDeepak KodihalliSome of the reasons PLDM sounds promising (some of these are advantages over 46d070b7d7SDeepak KodihalliIPMI): 47d070b7d7SDeepak Kodihalli 48d070b7d7SDeepak Kodihalli- Common in-band communication protocol. 49d070b7d7SDeepak Kodihalli 50d070b7d7SDeepak Kodihalli- Already existing PLDM Type specifications that cover the most common 51d070b7d7SDeepak Kodihalli communication requirements. Up to 64 PLDM Types can be defined (the last one 52d070b7d7SDeepak Kodihalli is OEM). At the moment, 6 are defined. Each PLDM type can house up to 256 PLDM 53d070b7d7SDeepak Kodihalli commands. 54d070b7d7SDeepak Kodihalli 55d070b7d7SDeepak Kodihalli- PLDM sensors are 2 bytes in length. 56d070b7d7SDeepak Kodihalli 57d070b7d7SDeepak Kodihalli- PLDM introduces the concept of effecters - a control mechanism. Both sensors 58d070b7d7SDeepak Kodihalli and effecters are associated to entities (similar to IPMI, entities can be 59d070b7d7SDeepak Kodihalli physical or logical), where sensors are a mechanism for monitoring and 60d070b7d7SDeepak Kodihalli effecters are a mechanism for control. Effecters can be numeric or state 61d070b7d7SDeepak Kodihalli based. PLDM defines commonly used entities and their IDs, but there 8K slots 62d070b7d7SDeepak Kodihalli available to define OEM entities. 63d070b7d7SDeepak Kodihalli 64d070b7d7SDeepak Kodihalli- A very active PLDM related working group in the DMTF. 65d070b7d7SDeepak Kodihalli 66d070b7d7SDeepak KodihalliThe plan is to run PLDM over MCTP. MCTP is defined in a spec of its own, and a 67d070b7d7SDeepak Kodihalliproposal on the MCTP design is in discussion already. There's going to be an 68d070b7d7SDeepak Kodihalliintermediate PLDM over MCTP binding layer, which lets us send PLDM messages over 69d070b7d7SDeepak KodihalliMCTP. This is defined in a spec of its own, and the design for this binding will 70d070b7d7SDeepak Kodihallibe proposed separately. 71d070b7d7SDeepak Kodihalli 72d070b7d7SDeepak Kodihalli## Requirements 73*f4febd00SPatrick Williams 74*f4febd00SPatrick WilliamsHow different BMC applications make use of PLDM messages is outside the scope of 75*f4febd00SPatrick Williamsthis requirements doc. The requirements listed here are related to the PLDM 76d070b7d7SDeepak Kodihalliprotocol stack and the request/response model: 77d070b7d7SDeepak Kodihalli 78d070b7d7SDeepak Kodihalli- Marshalling and unmarshalling of PLDM messages, defined in various PLDM Type 79d070b7d7SDeepak Kodihalli specs, must be implemented. This can of course be staged based on the need of 80d070b7d7SDeepak Kodihalli specific Types and functions. Since this is just encoding and decoding PLDM 81d070b7d7SDeepak Kodihalli messages, this can be a library that could shared between the BMC, and other 82d070b7d7SDeepak Kodihalli firmware stacks. The specifics of each PLDM Type (such as FRU table 83d070b7d7SDeepak Kodihalli structures, sensor PDR structures, etc) are implemented by this lib. 84d070b7d7SDeepak Kodihalli 85d070b7d7SDeepak Kodihalli- Mapping PLDM concepts to native OpenBMC concepts must be implemented. For 86d070b7d7SDeepak Kodihalli e.g.: mapping PLDM sensors to phosphor-hwmon hosted D-Bus objects, mapping 87d070b7d7SDeepak Kodihalli PLDM FRU data to D-Bus objects hosted by phosphor-inventory-manager, etc. The 88d070b7d7SDeepak Kodihalli mapping shouldn't be restrictive to D-Bus alone (meaning it shouldn't be 89d070b7d7SDeepak Kodihalli necessary to put objects on the Bus just to serve PLDM requests, a problem 90d070b7d7SDeepak Kodihalli that exists with phosphor-host-ipmid today). Essentially these are platform 91d070b7d7SDeepak Kodihalli specific PLDM message handlers. 92d070b7d7SDeepak Kodihalli 93d070b7d7SDeepak Kodihalli- The BMC should be able to act as a PLDM responder as well as a PLDM requester. 94d070b7d7SDeepak Kodihalli As a PLDM requester, the BMC can monitor/control other devices. As a PLDM 95d070b7d7SDeepak Kodihalli responder, the BMC can react to PLDM messages directed to it via requesters in 96d070b7d7SDeepak Kodihalli the platform. 97d070b7d7SDeepak Kodihalli 98d070b7d7SDeepak Kodihalli- As a PLDM requester, the BMC must be able to discover other PLDM enabled 99d070b7d7SDeepak Kodihalli components in the platform. 100d070b7d7SDeepak Kodihalli 101d070b7d7SDeepak Kodihalli- As a PLDM requester, the BMC must be able to send simultaneous messages to 102d070b7d7SDeepak Kodihalli different responders. 103d070b7d7SDeepak Kodihalli 104d070b7d7SDeepak Kodihalli- As a PLDM requester, the BMC must be able to handle out of order responses. 105d070b7d7SDeepak Kodihalli 106d070b7d7SDeepak Kodihalli- As a PLDM responder, the BMC may simultaneously respond to messages from 107d070b7d7SDeepak Kodihalli different requesters, but the spec doesn't mandate this. In other words the 108d070b7d7SDeepak Kodihalli responder could be single-threaded. 109d070b7d7SDeepak Kodihalli 110d070b7d7SDeepak Kodihalli- It should be possible to plug-in OEM PLDM types/functions into the PLDM stack. 111d070b7d7SDeepak Kodihalli 112d070b7d7SDeepak Kodihalli## Proposed Design 113*f4febd00SPatrick Williams 114d070b7d7SDeepak KodihalliThis document covers the architectural, interface, and design details. It 115d070b7d7SDeepak Kodihalliprovides recommendations for implementations, but implementation details are 116d070b7d7SDeepak Kodihallioutside the scope of this document. 117d070b7d7SDeepak Kodihalli 118d070b7d7SDeepak KodihalliThe design aims at having a single PLDM daemon serve both the requester and 119*f4febd00SPatrick Williamsresponder functions, and having transport specific endpoints to communicate on 120*f4febd00SPatrick Williamsdifferent channels. 121d070b7d7SDeepak Kodihalli 122d070b7d7SDeepak KodihalliThe design enables concurrency aspects of the requester and responder functions, 123d070b7d7SDeepak Kodihallibut the goal is to employ asynchronous IO and event loops, instead of multiple 124d070b7d7SDeepak Kodihallithreads, wherever possible. 125d070b7d7SDeepak Kodihalli 126d070b7d7SDeepak KodihalliThe following are high level structural elements of the design: 127d070b7d7SDeepak Kodihalli 128d070b7d7SDeepak Kodihalli### PLDM encode/decode libraries 129d070b7d7SDeepak Kodihalli 130d070b7d7SDeepak KodihalliThis library would take a PLDM message, decode it and extract the different 131d070b7d7SDeepak Kodihallifields of the message. Conversely, given a PLDM Type, command code, and the 132d070b7d7SDeepak Kodihallicommand's data fields, it would make a PLDM message. The thought is to design 133d070b7d7SDeepak Kodihallithis as a common library, that can be used by the BMC and other firmware stacks, 134d070b7d7SDeepak Kodihallibecause it's the encode/decode and protocol piece (and not the handling of a 135d070b7d7SDeepak Kodihallimessage). 136d070b7d7SDeepak Kodihalli 137d070b7d7SDeepak Kodihalli### PLDM provider libraries 138d070b7d7SDeepak Kodihalli 139d070b7d7SDeepak KodihalliThese libraries would implement the platform specific handling of incoming PLDM 140d070b7d7SDeepak Kodihallirequests (basically helping with the PLDM responder implementation, see next 141d070b7d7SDeepak Kodihallibullet point), so for instance they would query D-Bus objects (or even something 142d070b7d7SDeepak Kodihallilike a JSON file) to fetch platform specific information to respond to the PLDM 143d070b7d7SDeepak Kodihallimessage. They would link with the encode/decode lib. 144d070b7d7SDeepak Kodihalli 145d070b7d7SDeepak KodihalliIt should be possible to plug-in a provider library, that lets someone add 146d070b7d7SDeepak Kodihallifunctionality for new PLDM (standard as well as OEM) Types. The libraries would 147d070b7d7SDeepak Kodihalliimplement a "register" API to plug-in handlers for specific PLDM messages. 148d070b7d7SDeepak KodihalliSomething like: 149d070b7d7SDeepak Kodihalli 150*f4febd00SPatrick Williamstemplate <typename Handler, typename... args> auto register(uint8_t type, 151*f4febd00SPatrick Williamsuint8_t command, Handler handler); 152d070b7d7SDeepak Kodihalli 153d070b7d7SDeepak KodihalliThis allows for providing a strongly-typed C++ handler registration scheme. It 154d070b7d7SDeepak Kodihalliwould also be possible to validate the parameters passed to the handler at 155d070b7d7SDeepak Kodihallicompile time. 156d070b7d7SDeepak Kodihalli 157d070b7d7SDeepak Kodihalli### Request/Response Model 158d070b7d7SDeepak Kodihalli 159*f4febd00SPatrick WilliamsThe PLDM daemon links with the encode/decode and provider libs. The daemon would 160*f4febd00SPatrick Williamshave to implement the following functions: 161d070b7d7SDeepak Kodihalli 162d070b7d7SDeepak Kodihalli#### Receiver/Responder 163*f4febd00SPatrick Williams 164d070b7d7SDeepak KodihalliThe receiver wakes up on getting notified of incoming PLDM messages (via D-Bus 165d070b7d7SDeepak Kodihallisignal or callback from the transport layer) from a remote PLDM device. If the 166d070b7d7SDeepak Kodihallimessage type is "Request" it would route them to a PLDM provider library. Via 167d070b7d7SDeepak Kodihallithe library, asynchronous D-Bus calls (using sdbusplus-asio) would be made, so 168d070b7d7SDeepak Kodihallithat the receiver can register a handler for the D-Bus response, instead of 169d070b7d7SDeepak Kodihallihaving to wait for the D-Bus response. This way it can go back to listening for 170d070b7d7SDeepak Kodihalliincoming PLDM messages. 171d070b7d7SDeepak Kodihalli 172d070b7d7SDeepak KodihalliIn the D-Bus response handler, the receiver will send out the PLDM response 173d070b7d7SDeepak Kodihallimessage via the transport's send message API. If the transport's send message 174d070b7d7SDeepak KodihalliAPI blocks for a considerably long duration, then it would have to be run in a 175d070b7d7SDeepak Kodihallithread of it's own. 176d070b7d7SDeepak Kodihalli 177d070b7d7SDeepak KodihalliIf the incoming PLDM message is of type "Response", then the receiver emits a 178*f4febd00SPatrick WilliamsD-Bus signal pointing to the response message. Any time the message is too large 179*f4febd00SPatrick Williamsto fit in a D-Bus payload, the message is written to a file, and a read-only 180*f4febd00SPatrick Williamsfile descriptor pointing to that file is contained in the D-Bus signal. 181d070b7d7SDeepak Kodihalli 182d070b7d7SDeepak Kodihalli#### Requester 183*f4febd00SPatrick Williams 184d070b7d7SDeepak KodihalliDesigning the BMC as a PLDM requester is interesting. We haven't had this with 185d070b7d7SDeepak KodihalliIPMI, because the BMC was typically an IPMI server. PLDM requester functions 186d070b7d7SDeepak Kodihalliwill be spread across multiple OpenBMC applications (instead of a single big 187d070b7d7SDeepak Kodihallirequester app) - based on the responder they're talking to and the high level 188d070b7d7SDeepak Kodihallifunction they implement. For example, there could be an app that lets the BMC 189*f4febd00SPatrick Williamsupgrade firmware for other devices using PLDM - this would be a generic app in 190*f4febd00SPatrick Williamsthe sense that the same set of commands might have to be run irrespective of the 191*f4febd00SPatrick Williamsdevice on the other side. There could also be an app that does fan control on a 192*f4febd00SPatrick Williamsremote device, based on sensors from that device and algorithms specific to that 193*f4febd00SPatrick Williamsdevice. 194d070b7d7SDeepak Kodihalli 195e70b2ba6SDeepak Kodihalli##### Proposed requester design 196d070b7d7SDeepak Kodihalli 197e70b2ba6SDeepak KodihalliA requester app/flow comprises of the following : 198e70b2ba6SDeepak Kodihalli 199e70b2ba6SDeepak Kodihalli- Linkage with a PLDM encode/decode library, to be able to pack PLDM requests 200e70b2ba6SDeepak Kodihalli and unpack PLDM responses. 201e70b2ba6SDeepak Kodihalli 202e70b2ba6SDeepak Kodihalli- A D-Bus API to generate a unique PLDM instance id. The id needs to be unique 203*f4febd00SPatrick Williams across all outgoing PLDM messages (from potentially different processes). This 204*f4febd00SPatrick Williams needs to be on D-Bus because the id needs to be unique across PLDM requester 205*f4febd00SPatrick Williams app processes. 206e70b2ba6SDeepak Kodihalli 207e70b2ba6SDeepak Kodihalli- A requester client API that provides blocking and non-blocking functions to 208e70b2ba6SDeepak Kodihalli transfer a PLDM request message and to receive the corresponding response 209*f4febd00SPatrick Williams message, over MCTP (the blocking send() will return a PLDM response). This 210*f4febd00SPatrick Williams will be a thin wrapper over the socket API provided by the mctp demux daemon. 211*f4febd00SPatrick Williams This will provide APIs for common tasks so that the same may not be 212*f4febd00SPatrick Williams re-implemented in each PLDM requester app. This set of API will be built into 213*f4febd00SPatrick Williams the encode/decode library (so libpldm would house encode/decode APIs, and 214e70b2ba6SDeepak Kodihalli based on a compile time flag, the requester APIs as well). A PLDM requester 215e70b2ba6SDeepak Kodihalli app can choose to not use the client requester APIs, and instead can directly 216e70b2ba6SDeepak Kodihalli talk to the MCTP demux daemon. 217e70b2ba6SDeepak Kodihalli 218e70b2ba6SDeepak Kodihalli##### Proposed requester design - flow diagrams 219e70b2ba6SDeepak Kodihalli 220e70b2ba6SDeepak Kodihallia) With blocking API 221e70b2ba6SDeepak Kodihalli 2227c8847e9SDeepak Kodihalli``` 223e70b2ba6SDeepak Kodihalli+---------------+ +----------------+ +----------------+ +-----------------+ 224e70b2ba6SDeepak Kodihalli|BMC requester/ | |PLDM requester | |PLDM responder | |PLDM Daemon | 225e70b2ba6SDeepak Kodihalli|client app | |lib (part of | | | | | 226e70b2ba6SDeepak Kodihalli| | |libpldm) | | | | | 227e70b2ba6SDeepak Kodihalli+-------+-------+ +-------+--------+ +--------+-------+ +---------+-------+ 228e70b2ba6SDeepak Kodihalli | | | | 229e70b2ba6SDeepak Kodihalli |App starts | | | 230e70b2ba6SDeepak Kodihalli | | | | 231e70b2ba6SDeepak Kodihalli +------------------------------->setup connection with | | 232e70b2ba6SDeepak Kodihalli |init(non_block=false) |MCTP daemon | | 233e70b2ba6SDeepak Kodihalli | | | | 234e70b2ba6SDeepak Kodihalli +<-------+return_code+----------+ | | 235e70b2ba6SDeepak Kodihalli | | | | 236e70b2ba6SDeepak Kodihalli | | | | 237e70b2ba6SDeepak Kodihalli | | | | 238e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 239e70b2ba6SDeepak Kodihalli |encode_pldm_cmd(cmd code, args)| | | 240e70b2ba6SDeepak Kodihalli | | | | 241e70b2ba6SDeepak Kodihalli +<----+returns pldm_msg+--------+ | | 242e70b2ba6SDeepak Kodihalli | | | | 243e70b2ba6SDeepak Kodihalli | | | | 244e70b2ba6SDeepak Kodihalli |----------------------------------------------------------------------------------------------->| 245e70b2ba6SDeepak Kodihalli |DBus.getPLDMInstanceId() | | | 246e70b2ba6SDeepak Kodihalli | | | | 247e70b2ba6SDeepak Kodihalli |<-------------------------returns PLDM instance id----------------------------------------------| 248e70b2ba6SDeepak Kodihalli | | | | 249e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 250e70b2ba6SDeepak Kodihalli |send_msg(mctp_eids, pldm_msg) +----------------------------->+ | 251e70b2ba6SDeepak Kodihalli | |write msg to MCTP socket | | 252e70b2ba6SDeepak Kodihalli | +----------------------------->+ | 253e70b2ba6SDeepak Kodihalli | |call blocking recv() on socket| | 254e70b2ba6SDeepak Kodihalli | | | | 255e70b2ba6SDeepak Kodihalli | +<-+returns pldm_response+-----+ | 256e70b2ba6SDeepak Kodihalli | | | | 257e70b2ba6SDeepak Kodihalli | +----+ | | 258e70b2ba6SDeepak Kodihalli | | | verify eids, instance id| | 259e70b2ba6SDeepak Kodihalli | +<---+ | | 260e70b2ba6SDeepak Kodihalli | | | | 261e70b2ba6SDeepak Kodihalli +<--+returns pldm_response+-----+ | | 262e70b2ba6SDeepak Kodihalli | | | | 263e70b2ba6SDeepak Kodihalli | | | | 264e70b2ba6SDeepak Kodihalli | | | | 265e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 266e70b2ba6SDeepak Kodihalli |decode_pldm_cmd(pldm_resp, | | | 267e70b2ba6SDeepak Kodihalli | output args) | | | 268e70b2ba6SDeepak Kodihalli | | | | 269e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 270e70b2ba6SDeepak Kodihalli |close_connection() | | | 271e70b2ba6SDeepak Kodihalli + + + + 2727c8847e9SDeepak Kodihalli``` 273e70b2ba6SDeepak Kodihalli 274e70b2ba6SDeepak Kodihallib) With non-blocking API 275e70b2ba6SDeepak Kodihalli 2767c8847e9SDeepak Kodihalli``` 277e70b2ba6SDeepak Kodihalli+---------------+ +----------------+ +----------------+ +---------------+ 278e70b2ba6SDeepak Kodihalli|BMC requester/ | |PLDM requester | |PLDM responder | |PLDM daemon | 279e70b2ba6SDeepak Kodihalli|client app | |lib (part of | | | | | 280e70b2ba6SDeepak Kodihalli| | |libpldm) | | | | | 281e70b2ba6SDeepak Kodihalli+-------+-------+ +-------+--------+ +--------+-------+ +--------+------+ 282e70b2ba6SDeepak Kodihalli | | | | 283e70b2ba6SDeepak Kodihalli |App starts | | | 284e70b2ba6SDeepak Kodihalli | | | | 285e70b2ba6SDeepak Kodihalli +------------------------------->setup connection with | | 286e70b2ba6SDeepak Kodihalli |init(non_block=true |MCTP daemon | | 287e70b2ba6SDeepak Kodihalli | int* o_mctp_fd) | | | 288e70b2ba6SDeepak Kodihalli | | | | 289e70b2ba6SDeepak Kodihalli +<-------+return_code+----------+ | | 290e70b2ba6SDeepak Kodihalli | | | | 291e70b2ba6SDeepak Kodihalli | | | | 292e70b2ba6SDeepak Kodihalli | | | | 293e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 294e70b2ba6SDeepak Kodihalli |encode_pldm_cmd(cmd code, args)| | | 295e70b2ba6SDeepak Kodihalli | | | | 296e70b2ba6SDeepak Kodihalli +<----+returns pldm_msg+--------+ | | 297e70b2ba6SDeepak Kodihalli | | | | 298e70b2ba6SDeepak Kodihalli |-------------------------------------------------------------------------------------------->| 299e70b2ba6SDeepak Kodihalli |DBus.getPLDMInstanceId() | | | 300e70b2ba6SDeepak Kodihalli | | | | 301e70b2ba6SDeepak Kodihalli |<-------------------------returns PLDM instance id-------------------------------------------| 302e70b2ba6SDeepak Kodihalli | | | | 303e70b2ba6SDeepak Kodihalli | | | | 304e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 305e70b2ba6SDeepak Kodihalli |send_msg(eids, pldm_msg, +----------------------------->+ | 306e70b2ba6SDeepak Kodihalli | non_block=true) |write msg to MCTP socket | | 307e70b2ba6SDeepak Kodihalli | +<---+return_code+-------------+ | 308e70b2ba6SDeepak Kodihalli +<-+returns rc, doesn't block+--+ | | 309e70b2ba6SDeepak Kodihalli | | | | 310e70b2ba6SDeepak Kodihalli +------+ | | | 311e70b2ba6SDeepak Kodihalli | |Add EPOLLIN on mctp_fd | | | 312e70b2ba6SDeepak Kodihalli | |to self.event_loop | | | 313e70b2ba6SDeepak Kodihalli +<-----+ | | | 314e70b2ba6SDeepak Kodihalli | + | | 315e70b2ba6SDeepak Kodihalli +<----------------------+PLDM response msg written to mctp_fd+-+ | 316e70b2ba6SDeepak Kodihalli | + | | 317e70b2ba6SDeepak Kodihalli +------+EPOLLIN on mctp_fd | | | 318e70b2ba6SDeepak Kodihalli | |received | | | 319e70b2ba6SDeepak Kodihalli | | | | | 320e70b2ba6SDeepak Kodihalli +<-----+ | | | 321e70b2ba6SDeepak Kodihalli | | | | 322e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 323e70b2ba6SDeepak Kodihalli |decode_pldm_cmd(pldm_response) | | | 324e70b2ba6SDeepak Kodihalli | | | | 325e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 326e70b2ba6SDeepak Kodihalli |close_connection() | | | 327e70b2ba6SDeepak Kodihalli + + + + 3287c8847e9SDeepak Kodihalli``` 329e70b2ba6SDeepak Kodihalli 330e70b2ba6SDeepak Kodihalli##### Alternative to the proposed requester design 331e70b2ba6SDeepak Kodihalli 332e70b2ba6SDeepak Kodihallia) Define D-Bus interfaces to send and receive PLDM messages : 333e70b2ba6SDeepak Kodihalli 334e70b2ba6SDeepak Kodihalli``` 335e70b2ba6SDeepak Kodihallimethod sendPLDM(uint8 mctp_eid, uint8 msg[]) 336e70b2ba6SDeepak Kodihalli 337e70b2ba6SDeepak Kodihallisignal recvPLDM(uint8 mctp_eid, uint8 pldm_instance_id, uint8 msg[]) 338e70b2ba6SDeepak Kodihalli``` 339e70b2ba6SDeepak Kodihalli 340e70b2ba6SDeepak KodihalliPLDM requester apps can then invoke the above applications. While this 341e70b2ba6SDeepak Kodihallisimplifies things for the user, it has two disadvantages : 342*f4febd00SPatrick Williams 343e70b2ba6SDeepak Kodihalli- the app implementing such an interface could be a single point of failure, 344e70b2ba6SDeepak Kodihalli plus sending messages concurrently would be a challenge. 345e70b2ba6SDeepak Kodihalli- the message payload could be large (several pages), and copying the same for 346e70b2ba6SDeepak Kodihalli D-Bus transfers might be undesirable. 347d070b7d7SDeepak Kodihalli 348d070b7d7SDeepak Kodihalli### Multiple transport channels 349*f4febd00SPatrick Williams 350d070b7d7SDeepak KodihalliThe PLDM daemon might have to talk to remote PLDM devices via different 351d070b7d7SDeepak Kodihallichannels. While a level of abstraction might be provided by MCTP, the PLDM 352*f4febd00SPatrick Williamsdaemon would have to implement a D-Bus interface to target a specific transport 353*f4febd00SPatrick Williamschannel, so that requester apps on the BMC can send messages over that 354*f4febd00SPatrick Williamstransport. Also, it should be possible to plug-in platform specific D-Bus 355d070b7d7SDeepak Kodihalliobjects that implement an interface to target a platform specific transport. 356d070b7d7SDeepak Kodihalli 357a7ee8e1aSDeepak Kodihalli### Processing PLDM FRU information sent down by the host firmware 358a7ee8e1aSDeepak Kodihalli 359a7ee8e1aSDeepak KodihalliNote: while this is specific to the host BMC communication, most of this might 360a7ee8e1aSDeepak Kodihalliapply to processing PLDM FRU information received from a device connected to the 361a7ee8e1aSDeepak KodihalliBMC as well. 362a7ee8e1aSDeepak Kodihalli 363a7ee8e1aSDeepak KodihalliThe requirement is for the BMC to consume PLDM FRU information received from the 364a7ee8e1aSDeepak Kodihallihost firmware and then have the same exposed via Redfish. An example can be the 365a7ee8e1aSDeepak Kodihallihost firmware sending down processor and core information via PLDM FRU commands, 366a7ee8e1aSDeepak Kodihalliand the BMC making this information available via the Processor and 367a7ee8e1aSDeepak KodihalliProcessorCollection schemas. 368a7ee8e1aSDeepak Kodihalli 369a7ee8e1aSDeepak KodihalliThis design is built around the pldmd and entity-manager applications on the 370a7ee8e1aSDeepak KodihalliBMC: 371a7ee8e1aSDeepak Kodihalli 372a7ee8e1aSDeepak Kodihalli- The pldmd asks the host firmware's PLDM stack for the host's FRU record table, 373a7ee8e1aSDeepak Kodihalli by sending it the PLDM GetFRURecordTable command. The pldmd should send this 374a7ee8e1aSDeepak Kodihalli command if the host indicates support for the PLDM FRU spec. The pldmd 375a7ee8e1aSDeepak Kodihalli receives a PLDM FRU record table from the host firmware ( 376a7ee8e1aSDeepak Kodihalli www.dmtf.org/sites/default/files/standards/documents/DSP0257_1.0.0.pdf). The 377a7ee8e1aSDeepak Kodihalli daemon parses the FRU record table and hosts raw PLDM FRU information on 378a7ee8e1aSDeepak Kodihalli D-Bus. It will house the PLDM FRU properties for a certain FRU under an 379a7ee8e1aSDeepak Kodihalli xyz.openbmc_project.Inventory.Source.PLDM.FRU D-Bus interface, and house the 380a7ee8e1aSDeepak Kodihalli PLDM entity info extracted from the FRU record set PDR under an 381a7ee8e1aSDeepak Kodihalli xyz.openbmc_project.Source.PLDM.Entity interface. 382a7ee8e1aSDeepak Kodihalli 383a7ee8e1aSDeepak Kodihalli- Configurations can be written for entity-manager to probe an interface like 384a7ee8e1aSDeepak Kodihalli xyz.openbmc_project.Inventory.Source.PLDM.FRU, and create FRU inventory D-Bus 385a7ee8e1aSDeepak Kodihalli objects. Inventory interfaces from the xyz.openbmc_project. Inventory 386a7ee8e1aSDeepak Kodihalli namespace can be applied on these objects, by converting PLDM FRU property 387a7ee8e1aSDeepak Kodihalli values into xyz.openbmc_project.Invnetory.Decorator.Asset property values, 388a7ee8e1aSDeepak Kodihalli such as Part Number and Serial Number, in the entity manager configuration 389a7ee8e1aSDeepak Kodihalli file. Bmcweb can find these FRU inventory objects based on D-Bus interfaces, 390a7ee8e1aSDeepak Kodihalli as it does today. 391a7ee8e1aSDeepak Kodihalli 392d070b7d7SDeepak Kodihalli## Alternatives Considered 393*f4febd00SPatrick Williams 394*f4febd00SPatrick WilliamsContinue using IPMI, but start making more use of OEM extensions to suit the 395*f4febd00SPatrick Williamsrequirements of new platforms. However, given that the IPMI standard is no 396*f4febd00SPatrick Williamslonger under active development, we would likely end up with a large amount of 397*f4febd00SPatrick Williamsplatform-specific customisations. This also does not solve the hardware channel 398*f4febd00SPatrick Williamsissues in a standard manner. On OpenPOWER hardware at least, we've started to 399*f4febd00SPatrick Williamshit some of the limitations of IPMI (for example, we have need for >255 400*f4febd00SPatrick Williamssensors). 401d070b7d7SDeepak Kodihalli 402d070b7d7SDeepak Kodihalli## Impacts 403*f4febd00SPatrick Williams 404d070b7d7SDeepak KodihalliDevelopment would be required to implement the PLDM protocol, the 405d070b7d7SDeepak Kodihallirequest/response model, and platform specific handling. Low level design is 406d070b7d7SDeepak Kodihallirequired to implement the protocol specifics of each of the PLDM Types. Such low 407d070b7d7SDeepak Kodihallilevel design is not included in this proposal. 408d070b7d7SDeepak Kodihalli 409d070b7d7SDeepak KodihalliDesign and development needs to involve the firmware stacks of management 410d070b7d7SDeepak Kodihallicontrollers and management devices of a platform management subsystem. 411d070b7d7SDeepak Kodihalli 412d070b7d7SDeepak Kodihalli## Testing 413*f4febd00SPatrick Williams 414d070b7d7SDeepak KodihalliTesting can be done without having to depend on the underlying transport layer. 415d070b7d7SDeepak Kodihalli 416d070b7d7SDeepak KodihalliThe responder function can be tested by mocking a requester and the transport 417d070b7d7SDeepak Kodihallilayer: this would essentially test the protocol handling and platform specific 418d070b7d7SDeepak Kodihallihandling. The requester function can be tested by mocking a responder: this 419d070b7d7SDeepak Kodihalliwould test the instance id handling and the send/receive functions. 420d070b7d7SDeepak Kodihalli 421d070b7d7SDeepak KodihalliAPIs from the shared libraries can be tested via fuzzing. 422