commit | ef773059fdead2135c96c4a4c3520e4752012ef0 | [log] [tgz] |
---|---|---|
author | Manojkiran Eda <manojkiran.eda@gmail.com> | Thu Jul 29 09:29:28 2021 +0530 |
committer | ManojKiran Eda <manojkiran.eda@gmail.com> | Mon Jan 24 13:29:01 2022 +0000 |
tree | 6d9cdd406f6a97a536f4f6920c1db0b7df02a58c | |
parent | fb07542f39a32fee86b4e06d0932299e75fe2921 [diff] |
In-Memory FlightRecorder support for pldmd pldm daemon in BMC can act both as a requester and responder, and it is capable of talking to any device that talks pldm spec. With the rapid increase in the number of commands supported by pldmd, and also with the async request/response support enabled, its becomes extremely tough to debug the failures in the communication. And most of times, the essential information that is needed to debug are the last few commands that BMC pldm responded to. So this commit is an attempt to bring in an in-memory flight recorder that could save the last 10(can be configurable) pldm transactions in a circular buffer, and dumps the contents of it into a file when it receives a SIGUR1 signal. Resolves openbmc/pldm#24 Tested By : 1. Power on host 2. In the middle of poweron, send the SIGUSR1 signal to pldmd root@rain118bmc:/tmp# kill -10 836 Received SIGUR1(10) Signal interrupt root@rain118bmc:/tmp# Dumping the flight recorder into /tmp/pldm_flight_recorder 3. Make sure pldmd is not killed and does the rest of the power on operation. 4. check the contents of /tmp/pldm_flight_recorder root@p10bmc:~# cat /tmp/pldm_flight_recorder UTC Nov 05 / 11:27:25.334606 : Tx : 0a 3f 0d 00 UTC Nov 05 / 11:27:26.292988 : Rx : 09 01 8b 3f 0d 00 00 7b 1e 00 50 00 UTC Nov 05 / 11:27:26.296915 : Tx : 0b 3f 0d 00 UTC Nov 05 / 11:27:27.250999 : Rx : 09 01 8c 3f 0d 00 00 7c 1e 00 50 00 UTC Nov 05 / 11:27:27.254762 : Tx : 0c 3f 0d 00 UTC Nov 05 / 11:27:28.212168 : Rx : 09 01 8d 3f 0d 00 00 7d 1e 00 50 00 UTC Nov 05 / 11:27:28.216086 : Tx : 0d 3f 0d 00 UTC Nov 05 / 11:27:29.171228 : Rx : 09 01 8e 3f 0d 00 00 7e 1e 00 50 00 UTC Nov 05 / 11:27:29.175143 : Tx : 0e 3f 0d 00 UTC Nov 05 / 11:27:25.330716 : Rx : 09 01 8a 3f 0d 00 00 7a 1e 00 50 00 5. Configure with -Dflightrecorder-max-entries=0 root@p10bmc:~# kill -10 21847 Received SIGUR1(10) Signal interrupt Fight recorder policy is disabled Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com> Change-Id: I4e9c828f4ada9f1db6bf3a9b68c16e71b6e5d8f0
Need meson
and ninja
. Alternatively, source an OpenBMC ARM/x86 SDK.
meson build && ninja -C build
The simplest way of running the tests is as described by the meson man page:
meson builddir && meson test -C builddir
Alternatively, tests can be run in the OpenBMC CI docker container, or with an OpenBMC x86 sdk(see below for x86 steps).
meson -Doe-sdk=enabled build ninja -C build test
At a high-level, code in this repository belongs to one of the following three components.
This is a library which deals with the encoding and decoding of PLDM messages. It should be possible to use this library by projects other than OpenBMC, and hence certain constraints apply to it:
Source files are named according to the PLDM Type, for eg base.[h/c], fru.[h/c], etc.
Given a PLDM command "foo", the library will provide the following API: For the Requester function:
encode_foo_req() - encode a foo request decode_foo_resp() - decode a response to foo
For the Responder function:
decode_foo_req() - decode a foo request encode_foo_resp() - encode a response to foo
The library also provides API to pack and unpack PLDM headers.
This library provides handlers for incoming PLDM request messages. It provides for a registration as well as a plug-in mechanism. The library is implemented in modern C++, and handles OpenBMC's platform specifics.
The handlers are of the form
Response handler(Request payload, size_t payloadLen)
Source files are named according to the PLDM Type, for eg base.[hpp/cpp], fru.[hpp/cpp], etc.
This will support OEM or vendor-specific functions and semantic information. Following directory structure has to be used:
pldm repo |---- oem |----<oem_name> |----libpldm |----<oem based encoding and decoding files> |----libpldmresponder |---<oem based handler files>
<oem_name> - This folder must be created with the name of the OEM/vendor in lower case. Folders named libpldm and libpldmresponder must be created under the folder <oem_name>
Files having the oem functionality for the libpldm library should be placed under the folder oem/<oem_name>/libpldm. They must be adhering to the rules mentioned under the libpldm section above.
Files having the oem functionality for the libpldmresponder library should be placed under the folder oem/<oem_name>/libpldmresponder. They must be adhering to the rules mentioned under the libpldmresponder section above.
Once the above is done a meson option has to be created in pldm/meson_options.txt
with its mapped compiler flag to enable conditional compilation.
For consistency would recommend using "oem-<oem_name>".
The pldm/meson.build
and the corresponding source file(s) will need to incorporate the logic of adding its mapped compiler flag to allow conditional compilation of the code.
For more information on pldmtool please refer to plmdtool/README.md.
Consider hosting libpldm above in a repo of its own, probably even outside the OpenBMC project? A separate repo would enable something like git submodule.
This section documents important code flow paths.
a) PLDM daemon receives PLDM request message from underlying transport (MCTP).
b) PLDM daemon routes message to message handler, based on the PLDM command.
c) Message handler decodes request payload into various field(s) of the request message. It can make use of a decode_foo_req() API, and doesn't have to perform deserialization of the request payload by itself.
d) Message handler works with the request field(s) and generates response field(s).
e) Message handler prepares a response message. It can make use of an encode_foo_resp() API, and doesn't have to perform the serialization of the response field(s) by itself.
f) The PLDM daemon sends the response message prepared at step e) to the remote PLDM device.
a) A BMC PLDM requester app prepares a PLDM request message. There would be several requester apps (based on functionality/PLDM remote device). Each of them needn't bother with the serialization of request field(s), and can instead make use of an encode_foo_req() API.
b) BMC requester app requests PLDM daemon to send the request message to remote PLDM device.
c) Once the PLDM daemon receives a corresponding response message, it notifies the requester app.
d) The requester app has to work with the response field(s). It can make use of a decode_foo_resp() API to deserialize the response message.
While PLDM Platform Descriptor Records (PDRs) are mostly static information, they can vary across platforms and systems. For this reason, platform specific PDR information is encoded in platform specific JSON files. JSON files must be named based on the PDR type number. For example a state effecter PDR JSON file will be named 11.json. The JSON files may also include information to enable additional processing (apart from PDR creation) for specific PDR types, for eg mapping an effecter id to a D-Bus object.
The PLDM responder implementation finds and parses PDR JSON files to create the PDR repository. Platform specific PDR modifications would likely just result in JSON updates. New PDR type support would require JSON updates as well as PDR generation code. The PDR generator is a map of PDR Type -> C++ lambda to create PDR entries for that type based on the JSON, and to update the central PDR repo.