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 192e70b2ba6SDeepak Kodihalli##### Proposed requester design 193d070b7d7SDeepak Kodihalli 194e70b2ba6SDeepak KodihalliA requester app/flow comprises of the following : 195e70b2ba6SDeepak Kodihalli 196e70b2ba6SDeepak Kodihalli- Linkage with a PLDM encode/decode library, to be able to pack PLDM requests 197e70b2ba6SDeepak Kodihalli and unpack PLDM responses. 198e70b2ba6SDeepak Kodihalli 199e70b2ba6SDeepak Kodihalli- A D-Bus API to generate a unique PLDM instance id. The id needs to be unique 200e70b2ba6SDeepak Kodihalli across all outgoing PLDM messages (from potentially different processes). 201e70b2ba6SDeepak Kodihalli This needs to be on D-Bus because the id needs to be unique across PLDM 202e70b2ba6SDeepak Kodihalli requester app processes. 203e70b2ba6SDeepak Kodihalli 204e70b2ba6SDeepak Kodihalli- A requester client API that provides blocking and non-blocking functions to 205e70b2ba6SDeepak Kodihalli transfer a PLDM request message and to receive the corresponding response 206e70b2ba6SDeepak Kodihalli message, over MCTP (the blocking send() will return a PLDM response). 207e70b2ba6SDeepak Kodihalli This will be a thin wrapper over the socket API provided by the mctp demux 208e70b2ba6SDeepak Kodihalli daemon. This will provide APIs for common tasks so that the same may not 209e70b2ba6SDeepak Kodihalli be re-implemented in each PLDM requester app. This set of API will be built 210e70b2ba6SDeepak Kodihalli into the encode/decode library (so libpldm would house encode/decode APIs, and 211e70b2ba6SDeepak Kodihalli based on a compile time flag, the requester APIs as well). A PLDM requester 212e70b2ba6SDeepak Kodihalli app can choose to not use the client requester APIs, and instead can directly 213e70b2ba6SDeepak Kodihalli talk to the MCTP demux daemon. 214e70b2ba6SDeepak Kodihalli 215e70b2ba6SDeepak Kodihalli##### Proposed requester design - flow diagrams 216e70b2ba6SDeepak Kodihalli 217e70b2ba6SDeepak Kodihallia) With blocking API 218e70b2ba6SDeepak Kodihalli 2197c8847e9SDeepak Kodihalli``` 220e70b2ba6SDeepak Kodihalli+---------------+ +----------------+ +----------------+ +-----------------+ 221e70b2ba6SDeepak Kodihalli|BMC requester/ | |PLDM requester | |PLDM responder | |PLDM Daemon | 222e70b2ba6SDeepak Kodihalli|client app | |lib (part of | | | | | 223e70b2ba6SDeepak Kodihalli| | |libpldm) | | | | | 224e70b2ba6SDeepak Kodihalli+-------+-------+ +-------+--------+ +--------+-------+ +---------+-------+ 225e70b2ba6SDeepak Kodihalli | | | | 226e70b2ba6SDeepak Kodihalli |App starts | | | 227e70b2ba6SDeepak Kodihalli | | | | 228e70b2ba6SDeepak Kodihalli +------------------------------->setup connection with | | 229e70b2ba6SDeepak Kodihalli |init(non_block=false) |MCTP daemon | | 230e70b2ba6SDeepak Kodihalli | | | | 231e70b2ba6SDeepak Kodihalli +<-------+return_code+----------+ | | 232e70b2ba6SDeepak Kodihalli | | | | 233e70b2ba6SDeepak Kodihalli | | | | 234e70b2ba6SDeepak Kodihalli | | | | 235e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 236e70b2ba6SDeepak Kodihalli |encode_pldm_cmd(cmd code, args)| | | 237e70b2ba6SDeepak Kodihalli | | | | 238e70b2ba6SDeepak Kodihalli +<----+returns pldm_msg+--------+ | | 239e70b2ba6SDeepak Kodihalli | | | | 240e70b2ba6SDeepak Kodihalli | | | | 241e70b2ba6SDeepak Kodihalli |----------------------------------------------------------------------------------------------->| 242e70b2ba6SDeepak Kodihalli |DBus.getPLDMInstanceId() | | | 243e70b2ba6SDeepak Kodihalli | | | | 244e70b2ba6SDeepak Kodihalli |<-------------------------returns PLDM instance id----------------------------------------------| 245e70b2ba6SDeepak Kodihalli | | | | 246e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 247e70b2ba6SDeepak Kodihalli |send_msg(mctp_eids, pldm_msg) +----------------------------->+ | 248e70b2ba6SDeepak Kodihalli | |write msg to MCTP socket | | 249e70b2ba6SDeepak Kodihalli | +----------------------------->+ | 250e70b2ba6SDeepak Kodihalli | |call blocking recv() on socket| | 251e70b2ba6SDeepak Kodihalli | | | | 252e70b2ba6SDeepak Kodihalli | +<-+returns pldm_response+-----+ | 253e70b2ba6SDeepak Kodihalli | | | | 254e70b2ba6SDeepak Kodihalli | +----+ | | 255e70b2ba6SDeepak Kodihalli | | | verify eids, instance id| | 256e70b2ba6SDeepak Kodihalli | +<---+ | | 257e70b2ba6SDeepak Kodihalli | | | | 258e70b2ba6SDeepak Kodihalli +<--+returns pldm_response+-----+ | | 259e70b2ba6SDeepak Kodihalli | | | | 260e70b2ba6SDeepak Kodihalli | | | | 261e70b2ba6SDeepak Kodihalli | | | | 262e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 263e70b2ba6SDeepak Kodihalli |decode_pldm_cmd(pldm_resp, | | | 264e70b2ba6SDeepak Kodihalli | output args) | | | 265e70b2ba6SDeepak Kodihalli | | | | 266e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 267e70b2ba6SDeepak Kodihalli |close_connection() | | | 268e70b2ba6SDeepak Kodihalli + + + + 2697c8847e9SDeepak Kodihalli``` 270e70b2ba6SDeepak Kodihalli 271e70b2ba6SDeepak Kodihalli 272e70b2ba6SDeepak Kodihallib) With non-blocking API 273e70b2ba6SDeepak Kodihalli 2747c8847e9SDeepak Kodihalli``` 275e70b2ba6SDeepak Kodihalli+---------------+ +----------------+ +----------------+ +---------------+ 276e70b2ba6SDeepak Kodihalli|BMC requester/ | |PLDM requester | |PLDM responder | |PLDM daemon | 277e70b2ba6SDeepak Kodihalli|client app | |lib (part of | | | | | 278e70b2ba6SDeepak Kodihalli| | |libpldm) | | | | | 279e70b2ba6SDeepak Kodihalli+-------+-------+ +-------+--------+ +--------+-------+ +--------+------+ 280e70b2ba6SDeepak Kodihalli | | | | 281e70b2ba6SDeepak Kodihalli |App starts | | | 282e70b2ba6SDeepak Kodihalli | | | | 283e70b2ba6SDeepak Kodihalli +------------------------------->setup connection with | | 284e70b2ba6SDeepak Kodihalli |init(non_block=true |MCTP daemon | | 285e70b2ba6SDeepak Kodihalli | int* o_mctp_fd) | | | 286e70b2ba6SDeepak Kodihalli | | | | 287e70b2ba6SDeepak Kodihalli +<-------+return_code+----------+ | | 288e70b2ba6SDeepak Kodihalli | | | | 289e70b2ba6SDeepak Kodihalli | | | | 290e70b2ba6SDeepak Kodihalli | | | | 291e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 292e70b2ba6SDeepak Kodihalli |encode_pldm_cmd(cmd code, args)| | | 293e70b2ba6SDeepak Kodihalli | | | | 294e70b2ba6SDeepak Kodihalli +<----+returns pldm_msg+--------+ | | 295e70b2ba6SDeepak Kodihalli | | | | 296e70b2ba6SDeepak Kodihalli |-------------------------------------------------------------------------------------------->| 297e70b2ba6SDeepak Kodihalli |DBus.getPLDMInstanceId() | | | 298e70b2ba6SDeepak Kodihalli | | | | 299e70b2ba6SDeepak Kodihalli |<-------------------------returns PLDM instance id-------------------------------------------| 300e70b2ba6SDeepak Kodihalli | | | | 301e70b2ba6SDeepak Kodihalli | | | | 302e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 303e70b2ba6SDeepak Kodihalli |send_msg(eids, pldm_msg, +----------------------------->+ | 304e70b2ba6SDeepak Kodihalli | non_block=true) |write msg to MCTP socket | | 305e70b2ba6SDeepak Kodihalli | +<---+return_code+-------------+ | 306e70b2ba6SDeepak Kodihalli +<-+returns rc, doesn't block+--+ | | 307e70b2ba6SDeepak Kodihalli | | | | 308e70b2ba6SDeepak Kodihalli +------+ | | | 309e70b2ba6SDeepak Kodihalli | |Add EPOLLIN on mctp_fd | | | 310e70b2ba6SDeepak Kodihalli | |to self.event_loop | | | 311e70b2ba6SDeepak Kodihalli +<-----+ | | | 312e70b2ba6SDeepak Kodihalli | + | | 313e70b2ba6SDeepak Kodihalli +<----------------------+PLDM response msg written to mctp_fd+-+ | 314e70b2ba6SDeepak Kodihalli | + | | 315e70b2ba6SDeepak Kodihalli +------+EPOLLIN on mctp_fd | | | 316e70b2ba6SDeepak Kodihalli | |received | | | 317e70b2ba6SDeepak Kodihalli | | | | | 318e70b2ba6SDeepak Kodihalli +<-----+ | | | 319e70b2ba6SDeepak Kodihalli | | | | 320e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 321e70b2ba6SDeepak Kodihalli |decode_pldm_cmd(pldm_response) | | | 322e70b2ba6SDeepak Kodihalli | | | | 323e70b2ba6SDeepak Kodihalli +------------------------------>+ | | 324e70b2ba6SDeepak Kodihalli |close_connection() | | | 325e70b2ba6SDeepak Kodihalli + + + + 3267c8847e9SDeepak Kodihalli``` 327e70b2ba6SDeepak Kodihalli 328e70b2ba6SDeepak Kodihalli##### Alternative to the proposed requester design 329e70b2ba6SDeepak Kodihalli 330e70b2ba6SDeepak Kodihallia) Define D-Bus interfaces to send and receive PLDM messages : 331e70b2ba6SDeepak Kodihalli 332e70b2ba6SDeepak Kodihalli``` 333e70b2ba6SDeepak Kodihallimethod sendPLDM(uint8 mctp_eid, uint8 msg[]) 334e70b2ba6SDeepak Kodihalli 335e70b2ba6SDeepak Kodihallisignal recvPLDM(uint8 mctp_eid, uint8 pldm_instance_id, uint8 msg[]) 336e70b2ba6SDeepak Kodihalli``` 337e70b2ba6SDeepak Kodihalli 338e70b2ba6SDeepak KodihalliPLDM requester apps can then invoke the above applications. While this 339e70b2ba6SDeepak Kodihallisimplifies things for the user, it has two disadvantages : 340e70b2ba6SDeepak Kodihalli- the app implementing such an interface could be a single point of failure, 341e70b2ba6SDeepak Kodihalli plus sending messages concurrently would be a challenge. 342e70b2ba6SDeepak Kodihalli- the message payload could be large (several pages), and copying the same for 343e70b2ba6SDeepak Kodihalli D-Bus transfers might be undesirable. 344d070b7d7SDeepak Kodihalli 345d070b7d7SDeepak Kodihalli### Multiple transport channels 346d070b7d7SDeepak KodihalliThe PLDM daemon might have to talk to remote PLDM devices via different 347d070b7d7SDeepak Kodihallichannels. While a level of abstraction might be provided by MCTP, the PLDM 348d070b7d7SDeepak Kodihallidaemon would have to implement a D-Bus interface to target a specific 349d070b7d7SDeepak Kodihallitransport channel, so that requester apps on the BMC can send messages over 350d070b7d7SDeepak Kodihallithat transport. Also, it should be possible to plug-in platform specific D-Bus 351d070b7d7SDeepak Kodihalliobjects that implement an interface to target a platform specific transport. 352d070b7d7SDeepak Kodihalli 353*a7ee8e1aSDeepak Kodihalli### Processing PLDM FRU information sent down by the host firmware 354*a7ee8e1aSDeepak Kodihalli 355*a7ee8e1aSDeepak KodihalliNote: while this is specific to the host BMC communication, most of this might 356*a7ee8e1aSDeepak Kodihalliapply to processing PLDM FRU information received from a device connected to the 357*a7ee8e1aSDeepak KodihalliBMC as well. 358*a7ee8e1aSDeepak Kodihalli 359*a7ee8e1aSDeepak KodihalliThe requirement is for the BMC to consume PLDM FRU information received from the 360*a7ee8e1aSDeepak Kodihallihost firmware and then have the same exposed via Redfish. An example can be the 361*a7ee8e1aSDeepak Kodihallihost firmware sending down processor and core information via PLDM FRU commands, 362*a7ee8e1aSDeepak Kodihalliand the BMC making this information available via the Processor and 363*a7ee8e1aSDeepak KodihalliProcessorCollection schemas. 364*a7ee8e1aSDeepak Kodihalli 365*a7ee8e1aSDeepak KodihalliThis design is built around the pldmd and entity-manager applications on the 366*a7ee8e1aSDeepak KodihalliBMC: 367*a7ee8e1aSDeepak Kodihalli 368*a7ee8e1aSDeepak Kodihalli- The pldmd asks the host firmware's PLDM stack for the host's FRU record table, 369*a7ee8e1aSDeepak Kodihalli by sending it the PLDM GetFRURecordTable command. The pldmd should send this 370*a7ee8e1aSDeepak Kodihalli command if the host indicates support for the PLDM FRU spec. The pldmd 371*a7ee8e1aSDeepak Kodihalli receives a PLDM FRU record table from the host firmware ( 372*a7ee8e1aSDeepak Kodihalli www.dmtf.org/sites/default/files/standards/documents/DSP0257_1.0.0.pdf). The 373*a7ee8e1aSDeepak Kodihalli daemon parses the FRU record table and hosts raw PLDM FRU information on 374*a7ee8e1aSDeepak Kodihalli D-Bus. It will house the PLDM FRU properties for a certain FRU under an 375*a7ee8e1aSDeepak Kodihalli xyz.openbmc_project.Inventory.Source.PLDM.FRU D-Bus interface, and house the 376*a7ee8e1aSDeepak Kodihalli PLDM entity info extracted from the FRU record set PDR under an 377*a7ee8e1aSDeepak Kodihalli xyz.openbmc_project.Source.PLDM.Entity interface. 378*a7ee8e1aSDeepak Kodihalli 379*a7ee8e1aSDeepak Kodihalli- Configurations can be written for entity-manager to probe an interface like 380*a7ee8e1aSDeepak Kodihalli xyz.openbmc_project.Inventory.Source.PLDM.FRU, and create FRU inventory D-Bus 381*a7ee8e1aSDeepak Kodihalli objects. Inventory interfaces from the xyz.openbmc_project. Inventory 382*a7ee8e1aSDeepak Kodihalli namespace can be applied on these objects, by converting PLDM FRU property 383*a7ee8e1aSDeepak Kodihalli values into xyz.openbmc_project.Invnetory.Decorator.Asset property values, 384*a7ee8e1aSDeepak Kodihalli such as Part Number and Serial Number, in the entity manager configuration 385*a7ee8e1aSDeepak Kodihalli file. Bmcweb can find these FRU inventory objects based on D-Bus interfaces, 386*a7ee8e1aSDeepak Kodihalli as it does today. 387*a7ee8e1aSDeepak Kodihalli 388d070b7d7SDeepak Kodihalli## Alternatives Considered 389d070b7d7SDeepak KodihalliContinue using IPMI, but start making more use of OEM extensions to 390d070b7d7SDeepak Kodihallisuit the requirements of new platforms. However, given that the IPMI 391d070b7d7SDeepak Kodihallistandard is no longer under active development, we would likely end up 392d070b7d7SDeepak Kodihalliwith a large amount of platform-specific customisations. This also does 393d070b7d7SDeepak Kodihallinot solve the hardware channel issues in a standard manner. 394d070b7d7SDeepak KodihalliOn OpenPOWER hardware at least, we've started to hit some of the limitations of 395d070b7d7SDeepak KodihalliIPMI (for example, we have need for >255 sensors). 396d070b7d7SDeepak Kodihalli 397d070b7d7SDeepak Kodihalli## Impacts 398d070b7d7SDeepak KodihalliDevelopment would be required to implement the PLDM protocol, the 399d070b7d7SDeepak Kodihallirequest/response model, and platform specific handling. Low level design is 400d070b7d7SDeepak Kodihallirequired to implement the protocol specifics of each of the PLDM Types. Such low 401d070b7d7SDeepak Kodihallilevel design is not included in this proposal. 402d070b7d7SDeepak Kodihalli 403d070b7d7SDeepak KodihalliDesign and development needs to involve the firmware stacks of management 404d070b7d7SDeepak Kodihallicontrollers and management devices of a platform management subsystem. 405d070b7d7SDeepak Kodihalli 406d070b7d7SDeepak Kodihalli## Testing 407d070b7d7SDeepak KodihalliTesting can be done without having to depend on the underlying transport layer. 408d070b7d7SDeepak Kodihalli 409d070b7d7SDeepak KodihalliThe responder function can be tested by mocking a requester and the transport 410d070b7d7SDeepak Kodihallilayer: this would essentially test the protocol handling and platform specific 411d070b7d7SDeepak Kodihallihandling. The requester function can be tested by mocking a responder: this 412d070b7d7SDeepak Kodihalliwould test the instance id handling and the send/receive functions. 413d070b7d7SDeepak Kodihalli 414d070b7d7SDeepak KodihalliAPIs from the shared libraries can be tested via fuzzing. 415