1d070b7d7SDeepak Kodihalli# PLDM stack on OpenBMC 2d070b7d7SDeepak Kodihalli 3d070b7d7SDeepak KodihalliAuthor: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com> <dkodihal> 44134f4f1SDeepak Kodihalli 5d070b7d7SDeepak KodihalliPrimary assignee: Deepak Kodihalli 64134f4f1SDeepak Kodihalli 7d070b7d7SDeepak KodihalliCreated: 2019-01-22 8d070b7d7SDeepak Kodihalli 9d070b7d7SDeepak Kodihalli## Problem Description 10d070b7d7SDeepak KodihalliOn OpenBMC, in-band IPMI is currently the primary industry-standard means of 11d070b7d7SDeepak Kodihallicommunication between the BMC and the Host firmware. We've started hitting some 12d070b7d7SDeepak Kodihalliinherent limitations of IPMI on OpenPOWER servers: a limited number of sensors, 13d070b7d7SDeepak Kodihalliand a lack of a generic control mechanism (sensors are a generic monitoring 14d070b7d7SDeepak Kodihallimechanism) are the major ones. There is a need to improve upon the communication 15d070b7d7SDeepak Kodihalliprotocol, but at the same time inventing a custom protocol is undesirable. 16d070b7d7SDeepak Kodihalli 17d070b7d7SDeepak KodihalliThis design aims to employ Platform Level Data Model (PLDM), a standard 18d070b7d7SDeepak Kodihalliapplication layer communication protocol defined by the DMTF. PLDM draws inputs 19d070b7d7SDeepak Kodihallifrom IPMI, but it overcomes most of the latter's limitations. PLDM is also 20d070b7d7SDeepak Kodihallidesigned to run on standard transport protocols, for e.g. MCTP (also designed by 21d070b7d7SDeepak Kodihallithe DMTF). MCTP provides for a common transport layer over several physical 22d070b7d7SDeepak Kodihallichannels, by defining hardware bindings. The solution of PLDM over MCTP also 23d070b7d7SDeepak Kodihallihelps overcome some of the limitations of the hardware channels that IPMI uses. 24d070b7d7SDeepak Kodihalli 25d070b7d7SDeepak KodihalliPLDM's purpose is to enable all sorts of "inside the box communication": BMC - 26d070b7d7SDeepak KodihalliHost, BMC - BMC, BMC - Network Controller and BMC - Other (for e.g. sensor) 27d070b7d7SDeepak Kodihallidevices. 28d070b7d7SDeepak Kodihalli 29d070b7d7SDeepak Kodihalli## Background and References 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 37d070b7d7SDeepak KodihalliPLDM groups commands under broader functions, and defines 38d070b7d7SDeepak Kodihalliseparate specifications for each of these functions (also called PLDM "Types"). 39d070b7d7SDeepak KodihalliThe currently 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 73d070b7d7SDeepak KodihalliHow different BMC applications make use of PLDM messages is outside the scope 74d070b7d7SDeepak Kodihalliof this requirements doc. The requirements listed here are related to the PLDM 75d070b7d7SDeepak Kodihalliprotocol stack and the request/response model: 76d070b7d7SDeepak Kodihalli 77d070b7d7SDeepak Kodihalli- Marshalling and unmarshalling of PLDM messages, defined in various PLDM Type 78d070b7d7SDeepak Kodihalli specs, must be implemented. This can of course be staged based on the need of 79d070b7d7SDeepak Kodihalli specific Types and functions. Since this is just encoding and decoding PLDM 80d070b7d7SDeepak Kodihalli messages, this can be a library that could shared between the BMC, and other 81d070b7d7SDeepak Kodihalli firmware stacks. The specifics of each PLDM Type (such as FRU table 82d070b7d7SDeepak Kodihalli structures, sensor PDR structures, etc) are implemented by this lib. 83d070b7d7SDeepak Kodihalli 84d070b7d7SDeepak Kodihalli- Mapping PLDM concepts to native OpenBMC concepts must be implemented. For 85d070b7d7SDeepak Kodihalli e.g.: mapping PLDM sensors to phosphor-hwmon hosted D-Bus objects, mapping 86d070b7d7SDeepak Kodihalli PLDM FRU data to D-Bus objects hosted by phosphor-inventory-manager, etc. The 87d070b7d7SDeepak Kodihalli mapping shouldn't be restrictive to D-Bus alone (meaning it shouldn't be 88d070b7d7SDeepak Kodihalli necessary to put objects on the Bus just to serve PLDM requests, a problem 89d070b7d7SDeepak Kodihalli that exists with phosphor-host-ipmid today). Essentially these are platform 90d070b7d7SDeepak Kodihalli specific PLDM message handlers. 91d070b7d7SDeepak Kodihalli 92d070b7d7SDeepak Kodihalli- The BMC should be able to act as a PLDM responder as well as a PLDM requester. 93d070b7d7SDeepak Kodihalli As a PLDM requester, the BMC can monitor/control other devices. As a PLDM 94d070b7d7SDeepak Kodihalli responder, the BMC can react to PLDM messages directed to it via requesters in 95d070b7d7SDeepak Kodihalli the platform. 96d070b7d7SDeepak Kodihalli 97d070b7d7SDeepak Kodihalli- As a PLDM requester, the BMC must be able to discover other PLDM enabled 98d070b7d7SDeepak Kodihalli components in the platform. 99d070b7d7SDeepak Kodihalli 100d070b7d7SDeepak Kodihalli- As a PLDM requester, the BMC must be able to send simultaneous messages to 101d070b7d7SDeepak Kodihalli different responders. 102d070b7d7SDeepak Kodihalli 103d070b7d7SDeepak Kodihalli- As a PLDM requester, the BMC must be able to handle out of order responses. 104d070b7d7SDeepak Kodihalli 105d070b7d7SDeepak Kodihalli- As a PLDM responder, the BMC may simultaneously respond to messages from 106d070b7d7SDeepak Kodihalli different requesters, but the spec doesn't mandate this. In other words the 107d070b7d7SDeepak Kodihalli responder could be single-threaded. 108d070b7d7SDeepak Kodihalli 109d070b7d7SDeepak Kodihalli- It should be possible to plug-in OEM PLDM types/functions into the PLDM stack. 110d070b7d7SDeepak Kodihalli 111d070b7d7SDeepak Kodihalli## Proposed Design 112d070b7d7SDeepak KodihalliThis document covers the architectural, interface, and design details. It 113d070b7d7SDeepak Kodihalliprovides recommendations for implementations, but implementation details are 114d070b7d7SDeepak Kodihallioutside the scope of this document. 115d070b7d7SDeepak Kodihalli 116d070b7d7SDeepak KodihalliThe design aims at having a single PLDM daemon serve both the requester and 117d070b7d7SDeepak Kodihalliresponder functions, and having transport specific endpoints to communicate 118d070b7d7SDeepak Kodihallion different channels. 119d070b7d7SDeepak Kodihalli 120d070b7d7SDeepak KodihalliThe design enables concurrency aspects of the requester and responder functions, 121d070b7d7SDeepak Kodihallibut the goal is to employ asynchronous IO and event loops, instead of multiple 122d070b7d7SDeepak Kodihallithreads, wherever possible. 123d070b7d7SDeepak Kodihalli 124d070b7d7SDeepak KodihalliThe following are high level structural elements of the design: 125d070b7d7SDeepak Kodihalli 126d070b7d7SDeepak Kodihalli### PLDM encode/decode libraries 127d070b7d7SDeepak Kodihalli 128d070b7d7SDeepak KodihalliThis library would take a PLDM message, decode it and extract the different 129d070b7d7SDeepak Kodihallifields of the message. Conversely, given a PLDM Type, command code, and the 130d070b7d7SDeepak Kodihallicommand's data fields, it would make a PLDM message. The thought is to design 131d070b7d7SDeepak Kodihallithis as a common library, that can be used by the BMC and other firmware stacks, 132d070b7d7SDeepak Kodihallibecause it's the encode/decode and protocol piece (and not the handling of a 133d070b7d7SDeepak Kodihallimessage). 134d070b7d7SDeepak Kodihalli 135d070b7d7SDeepak Kodihalli### PLDM provider libraries 136d070b7d7SDeepak Kodihalli 137d070b7d7SDeepak KodihalliThese libraries would implement the platform specific handling of incoming PLDM 138d070b7d7SDeepak Kodihallirequests (basically helping with the PLDM responder implementation, see next 139d070b7d7SDeepak Kodihallibullet point), so for instance they would query D-Bus objects (or even something 140d070b7d7SDeepak Kodihallilike a JSON file) to fetch platform specific information to respond to the PLDM 141d070b7d7SDeepak Kodihallimessage. They would link with the encode/decode lib. 142d070b7d7SDeepak Kodihalli 143d070b7d7SDeepak KodihalliIt should be possible to plug-in a provider library, that lets someone add 144d070b7d7SDeepak Kodihallifunctionality for new PLDM (standard as well as OEM) Types. The libraries would 145d070b7d7SDeepak Kodihalliimplement a "register" API to plug-in handlers for specific PLDM messages. 146d070b7d7SDeepak KodihalliSomething like: 147d070b7d7SDeepak Kodihalli 148d070b7d7SDeepak Kodihallitemplate <typename Handler, typename... args> 149d070b7d7SDeepak Kodihalliauto register(uint8_t type, uint8_t command, Handler handler); 150d070b7d7SDeepak Kodihalli 151d070b7d7SDeepak KodihalliThis allows for providing a strongly-typed C++ handler registration scheme. It 152d070b7d7SDeepak Kodihalliwould also be possible to validate the parameters passed to the handler at 153d070b7d7SDeepak Kodihallicompile time. 154d070b7d7SDeepak Kodihalli 155d070b7d7SDeepak Kodihalli### Request/Response Model 156d070b7d7SDeepak Kodihalli 157d070b7d7SDeepak KodihalliThe PLDM daemon links with the encode/decode and provider libs. The daemon 158d070b7d7SDeepak Kodihalliwould have to implement the following functions: 159d070b7d7SDeepak Kodihalli 160d070b7d7SDeepak Kodihalli#### Receiver/Responder 161d070b7d7SDeepak KodihalliThe receiver wakes up on getting notified of incoming PLDM messages (via D-Bus 162d070b7d7SDeepak Kodihallisignal or callback from the transport layer) from a remote PLDM device. If the 163d070b7d7SDeepak Kodihallimessage type is "Request" it would route them to a PLDM provider library. Via 164d070b7d7SDeepak Kodihallithe library, asynchronous D-Bus calls (using sdbusplus-asio) would be made, so 165d070b7d7SDeepak Kodihallithat the receiver can register a handler for the D-Bus response, instead of 166d070b7d7SDeepak Kodihallihaving to wait for the D-Bus response. This way it can go back to listening for 167d070b7d7SDeepak Kodihalliincoming PLDM messages. 168d070b7d7SDeepak Kodihalli 169d070b7d7SDeepak KodihalliIn the D-Bus response handler, the receiver will send out the PLDM response 170d070b7d7SDeepak Kodihallimessage via the transport's send message API. If the transport's send message 171d070b7d7SDeepak KodihalliAPI blocks for a considerably long duration, then it would have to be run in a 172d070b7d7SDeepak Kodihallithread of it's own. 173d070b7d7SDeepak Kodihalli 174d070b7d7SDeepak KodihalliIf the incoming PLDM message is of type "Response", then the receiver emits a 175d070b7d7SDeepak KodihalliD-Bus signal pointing to the response message. Any time the message is too 176d070b7d7SDeepak Kodihallilarge to fit in a D-Bus payload, the message is written to a file, and a 177d070b7d7SDeepak Kodihalliread-only file descriptor pointing to that file is contained in the D-Bus 178d070b7d7SDeepak Kodihallisignal. 179d070b7d7SDeepak Kodihalli 180d070b7d7SDeepak Kodihalli#### Requester 181d070b7d7SDeepak KodihalliDesigning the BMC as a PLDM requester is interesting. We haven't had this with 182d070b7d7SDeepak KodihalliIPMI, because the BMC was typically an IPMI server. PLDM requester functions 183d070b7d7SDeepak Kodihalliwill be spread across multiple OpenBMC applications (instead of a single big 184d070b7d7SDeepak Kodihallirequester app) - based on the responder they're talking to and the high level 185d070b7d7SDeepak Kodihallifunction they implement. For example, there could be an app that lets the BMC 186d070b7d7SDeepak Kodihalliupgrade firmware for other devices using PLDM - this would be a generic app 187d070b7d7SDeepak Kodihalliin the sense that the same set of commands might have to be run irrespective 188d070b7d7SDeepak Kodihalliof the device on the other side. There could also be an app that does fan 189d070b7d7SDeepak Kodihallicontrol on a remote device, based on sensors from that device and algorithms 190d070b7d7SDeepak Kodihallispecific to that device. 191d070b7d7SDeepak Kodihalli 192*e70b2ba6SDeepak Kodihalli##### Proposed requester design 193d070b7d7SDeepak Kodihalli 194*e70b2ba6SDeepak KodihalliA requester app/flow comprises of the following : 195*e70b2ba6SDeepak Kodihalli 196*e70b2ba6SDeepak Kodihalli- Linkage with a PLDM encode/decode library, to be able to pack PLDM requests 197*e70b2ba6SDeepak Kodihalli and unpack PLDM responses. 198*e70b2ba6SDeepak Kodihalli 199*e70b2ba6SDeepak Kodihalli- A D-Bus API to generate a unique PLDM instance id. The id needs to be unique 200*e70b2ba6SDeepak Kodihalli across all outgoing PLDM messages (from potentially different processes). 201*e70b2ba6SDeepak Kodihalli This needs to be on D-Bus because the id needs to be unique across PLDM 202*e70b2ba6SDeepak Kodihalli requester app processes. 203*e70b2ba6SDeepak Kodihalli 204*e70b2ba6SDeepak Kodihalli- A requester client API that provides blocking and non-blocking functions to 205*e70b2ba6SDeepak Kodihalli transfer a PLDM request message and to receive the corresponding response 206*e70b2ba6SDeepak Kodihalli message, over MCTP (the blocking send() will return a PLDM response). 207*e70b2ba6SDeepak Kodihalli This will be a thin wrapper over the socket API provided by the mctp demux 208*e70b2ba6SDeepak Kodihalli daemon. This will provide APIs for common tasks so that the same may not 209*e70b2ba6SDeepak Kodihalli be re-implemented in each PLDM requester app. This set of API will be built 210*e70b2ba6SDeepak Kodihalli into the encode/decode library (so libpldm would house encode/decode APIs, and 211*e70b2ba6SDeepak Kodihalli based on a compile time flag, the requester APIs as well). A PLDM requester 212*e70b2ba6SDeepak Kodihalli app can choose to not use the client requester APIs, and instead can directly 213*e70b2ba6SDeepak Kodihalli talk to the MCTP demux daemon. 214*e70b2ba6SDeepak Kodihalli 215*e70b2ba6SDeepak Kodihalli##### Proposed requester design - flow diagrams 216*e70b2ba6SDeepak Kodihalli 217*e70b2ba6SDeepak Kodihallia) With blocking API 218*e70b2ba6SDeepak Kodihalli 219*e70b2ba6SDeepak Kodihalli+---------------+ +----------------+ +----------------+ +-----------------+ 220*e70b2ba6SDeepak Kodihalli|BMC requester/ | |PLDM requester | |PLDM responder | |PLDM Daemon | 221*e70b2ba6SDeepak Kodihalli|client app | |lib (part of | | | | | 222*e70b2ba6SDeepak Kodihalli| | |libpldm) | | | | | 223*e70b2ba6SDeepak Kodihalli+-------+-------+ +-------+--------+ +--------+-------+ +---------+-------+ 224*e70b2ba6SDeepak Kodihalli | | | | 225*e70b2ba6SDeepak Kodihalli |App starts | | | 226*e70b2ba6SDeepak Kodihalli | | | | 227*e70b2ba6SDeepak Kodihalli +------------------------------->setup connection with | | 228*e70b2ba6SDeepak Kodihalli |init(non_block=false) |MCTP daemon | | 229*e70b2ba6SDeepak Kodihalli | | | | 230*e70b2ba6SDeepak Kodihalli +<-------+return_code+----------+ | | 231*e70b2ba6SDeepak Kodihalli | | | | 232*e70b2ba6SDeepak Kodihalli | | | | 233*e70b2ba6SDeepak Kodihalli | | | | 234*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 235*e70b2ba6SDeepak Kodihalli |encode_pldm_cmd(cmd code, args)| | | 236*e70b2ba6SDeepak Kodihalli | | | | 237*e70b2ba6SDeepak Kodihalli +<----+returns pldm_msg+--------+ | | 238*e70b2ba6SDeepak Kodihalli | | | | 239*e70b2ba6SDeepak Kodihalli | | | | 240*e70b2ba6SDeepak Kodihalli |----------------------------------------------------------------------------------------------->| 241*e70b2ba6SDeepak Kodihalli |DBus.getPLDMInstanceId() | | | 242*e70b2ba6SDeepak Kodihalli | | | | 243*e70b2ba6SDeepak Kodihalli |<-------------------------returns PLDM instance id----------------------------------------------| 244*e70b2ba6SDeepak Kodihalli | | | | 245*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 246*e70b2ba6SDeepak Kodihalli |send_msg(mctp_eids, pldm_msg) +----------------------------->+ | 247*e70b2ba6SDeepak Kodihalli | |write msg to MCTP socket | | 248*e70b2ba6SDeepak Kodihalli | +----------------------------->+ | 249*e70b2ba6SDeepak Kodihalli | |call blocking recv() on socket| | 250*e70b2ba6SDeepak Kodihalli | | | | 251*e70b2ba6SDeepak Kodihalli | +<-+returns pldm_response+-----+ | 252*e70b2ba6SDeepak Kodihalli | | | | 253*e70b2ba6SDeepak Kodihalli | +----+ | | 254*e70b2ba6SDeepak Kodihalli | | | verify eids, instance id| | 255*e70b2ba6SDeepak Kodihalli | +<---+ | | 256*e70b2ba6SDeepak Kodihalli | | | | 257*e70b2ba6SDeepak Kodihalli +<--+returns pldm_response+-----+ | | 258*e70b2ba6SDeepak Kodihalli | | | | 259*e70b2ba6SDeepak Kodihalli | | | | 260*e70b2ba6SDeepak Kodihalli | | | | 261*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 262*e70b2ba6SDeepak Kodihalli |decode_pldm_cmd(pldm_resp, | | | 263*e70b2ba6SDeepak Kodihalli | output args) | | | 264*e70b2ba6SDeepak Kodihalli | | | | 265*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 266*e70b2ba6SDeepak Kodihalli |close_connection() | | | 267*e70b2ba6SDeepak Kodihalli + + + + 268*e70b2ba6SDeepak Kodihalli 269*e70b2ba6SDeepak Kodihalli 270*e70b2ba6SDeepak Kodihallib) With non-blocking API 271*e70b2ba6SDeepak Kodihalli 272*e70b2ba6SDeepak Kodihalli+---------------+ +----------------+ +----------------+ +---------------+ 273*e70b2ba6SDeepak Kodihalli|BMC requester/ | |PLDM requester | |PLDM responder | |PLDM daemon | 274*e70b2ba6SDeepak Kodihalli|client app | |lib (part of | | | | | 275*e70b2ba6SDeepak Kodihalli| | |libpldm) | | | | | 276*e70b2ba6SDeepak Kodihalli+-------+-------+ +-------+--------+ +--------+-------+ +--------+------+ 277*e70b2ba6SDeepak Kodihalli | | | | 278*e70b2ba6SDeepak Kodihalli |App starts | | | 279*e70b2ba6SDeepak Kodihalli | | | | 280*e70b2ba6SDeepak Kodihalli +------------------------------->setup connection with | | 281*e70b2ba6SDeepak Kodihalli |init(non_block=true |MCTP daemon | | 282*e70b2ba6SDeepak Kodihalli | int* o_mctp_fd) | | | 283*e70b2ba6SDeepak Kodihalli | | | | 284*e70b2ba6SDeepak Kodihalli +<-------+return_code+----------+ | | 285*e70b2ba6SDeepak Kodihalli | | | | 286*e70b2ba6SDeepak Kodihalli | | | | 287*e70b2ba6SDeepak Kodihalli | | | | 288*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 289*e70b2ba6SDeepak Kodihalli |encode_pldm_cmd(cmd code, args)| | | 290*e70b2ba6SDeepak Kodihalli | | | | 291*e70b2ba6SDeepak Kodihalli +<----+returns pldm_msg+--------+ | | 292*e70b2ba6SDeepak Kodihalli | | | | 293*e70b2ba6SDeepak Kodihalli |-------------------------------------------------------------------------------------------->| 294*e70b2ba6SDeepak Kodihalli |DBus.getPLDMInstanceId() | | | 295*e70b2ba6SDeepak Kodihalli | | | | 296*e70b2ba6SDeepak Kodihalli |<-------------------------returns PLDM instance id-------------------------------------------| 297*e70b2ba6SDeepak Kodihalli | | | | 298*e70b2ba6SDeepak Kodihalli | | | | 299*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 300*e70b2ba6SDeepak Kodihalli |send_msg(eids, pldm_msg, +----------------------------->+ | 301*e70b2ba6SDeepak Kodihalli | non_block=true) |write msg to MCTP socket | | 302*e70b2ba6SDeepak Kodihalli | +<---+return_code+-------------+ | 303*e70b2ba6SDeepak Kodihalli +<-+returns rc, doesn't block+--+ | | 304*e70b2ba6SDeepak Kodihalli | | | | 305*e70b2ba6SDeepak Kodihalli +------+ | | | 306*e70b2ba6SDeepak Kodihalli | |Add EPOLLIN on mctp_fd | | | 307*e70b2ba6SDeepak Kodihalli | |to self.event_loop | | | 308*e70b2ba6SDeepak Kodihalli +<-----+ | | | 309*e70b2ba6SDeepak Kodihalli | + | | 310*e70b2ba6SDeepak Kodihalli +<----------------------+PLDM response msg written to mctp_fd+-+ | 311*e70b2ba6SDeepak Kodihalli | + | | 312*e70b2ba6SDeepak Kodihalli +------+EPOLLIN on mctp_fd | | | 313*e70b2ba6SDeepak Kodihalli | |received | | | 314*e70b2ba6SDeepak Kodihalli | | | | | 315*e70b2ba6SDeepak Kodihalli +<-----+ | | | 316*e70b2ba6SDeepak Kodihalli | | | | 317*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 318*e70b2ba6SDeepak Kodihalli |decode_pldm_cmd(pldm_response) | | | 319*e70b2ba6SDeepak Kodihalli | | | | 320*e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 321*e70b2ba6SDeepak Kodihalli |close_connection() | | | 322*e70b2ba6SDeepak Kodihalli + + + + 323*e70b2ba6SDeepak Kodihalli 324*e70b2ba6SDeepak Kodihalli##### Alternative to the proposed requester design 325*e70b2ba6SDeepak Kodihalli 326*e70b2ba6SDeepak Kodihallia) Define D-Bus interfaces to send and receive PLDM messages : 327*e70b2ba6SDeepak Kodihalli 328*e70b2ba6SDeepak Kodihalli``` 329*e70b2ba6SDeepak Kodihallimethod sendPLDM(uint8 mctp_eid, uint8 msg[]) 330*e70b2ba6SDeepak Kodihalli 331*e70b2ba6SDeepak Kodihallisignal recvPLDM(uint8 mctp_eid, uint8 pldm_instance_id, uint8 msg[]) 332*e70b2ba6SDeepak Kodihalli``` 333*e70b2ba6SDeepak Kodihalli 334*e70b2ba6SDeepak KodihalliPLDM requester apps can then invoke the above applications. While this 335*e70b2ba6SDeepak Kodihallisimplifies things for the user, it has two disadvantages : 336*e70b2ba6SDeepak Kodihalli- the app implementing such an interface could be a single point of failure, 337*e70b2ba6SDeepak Kodihalli plus sending messages concurrently would be a challenge. 338*e70b2ba6SDeepak Kodihalli- the message payload could be large (several pages), and copying the same for 339*e70b2ba6SDeepak Kodihalli D-Bus transfers might be undesirable. 340d070b7d7SDeepak Kodihalli 341d070b7d7SDeepak Kodihalli### Multiple transport channels 342d070b7d7SDeepak KodihalliThe PLDM daemon might have to talk to remote PLDM devices via different 343d070b7d7SDeepak Kodihallichannels. While a level of abstraction might be provided by MCTP, the PLDM 344d070b7d7SDeepak Kodihallidaemon would have to implement a D-Bus interface to target a specific 345d070b7d7SDeepak Kodihallitransport channel, so that requester apps on the BMC can send messages over 346d070b7d7SDeepak Kodihallithat transport. Also, it should be possible to plug-in platform specific D-Bus 347d070b7d7SDeepak Kodihalliobjects that implement an interface to target a platform specific transport. 348d070b7d7SDeepak Kodihalli 349d070b7d7SDeepak Kodihalli## Alternatives Considered 350d070b7d7SDeepak KodihalliContinue using IPMI, but start making more use of OEM extensions to 351d070b7d7SDeepak Kodihallisuit the requirements of new platforms. However, given that the IPMI 352d070b7d7SDeepak Kodihallistandard is no longer under active development, we would likely end up 353d070b7d7SDeepak Kodihalliwith a large amount of platform-specific customisations. This also does 354d070b7d7SDeepak Kodihallinot solve the hardware channel issues in a standard manner. 355d070b7d7SDeepak KodihalliOn OpenPOWER hardware at least, we've started to hit some of the limitations of 356d070b7d7SDeepak KodihalliIPMI (for example, we have need for >255 sensors). 357d070b7d7SDeepak Kodihalli 358d070b7d7SDeepak Kodihalli## Impacts 359d070b7d7SDeepak KodihalliDevelopment would be required to implement the PLDM protocol, the 360d070b7d7SDeepak Kodihallirequest/response model, and platform specific handling. Low level design is 361d070b7d7SDeepak Kodihallirequired to implement the protocol specifics of each of the PLDM Types. Such low 362d070b7d7SDeepak Kodihallilevel design is not included in this proposal. 363d070b7d7SDeepak Kodihalli 364d070b7d7SDeepak KodihalliDesign and development needs to involve the firmware stacks of management 365d070b7d7SDeepak Kodihallicontrollers and management devices of a platform management subsystem. 366d070b7d7SDeepak Kodihalli 367d070b7d7SDeepak Kodihalli## Testing 368d070b7d7SDeepak KodihalliTesting can be done without having to depend on the underlying transport layer. 369d070b7d7SDeepak Kodihalli 370d070b7d7SDeepak KodihalliThe responder function can be tested by mocking a requester and the transport 371d070b7d7SDeepak Kodihallilayer: this would essentially test the protocol handling and platform specific 372d070b7d7SDeepak Kodihallihandling. The requester function can be tested by mocking a responder: this 373d070b7d7SDeepak Kodihalliwould test the instance id handling and the send/receive functions. 374d070b7d7SDeepak Kodihalli 375d070b7d7SDeepak KodihalliAPIs from the shared libraries can be tested via fuzzing. 376