fw-update: reject mismatched EID in ItemUpdateManager dispatch ItemUpdateManager::handleRequest declared its eid parameter as mctp_eid_t /*eid*/ and dispatched purely on command. Combined with AggregateUpdateManager iterating updateManagers in SoftwareIdentifier (i.e. eid-then-component) order, whichever active ItemUpdateManager came first claimed every FW-update response regardless of the inbound EID. Two concurrent target updates on different EIDs would have all responses funneled to the lower-EID manager. Concretely: with an update on EID 12 in flight, starting an update on EID 10 created ItemUpdateManager(10). EID 12's apply_complete was then consumed by deviceUpdater10 and logged as if it belonged to EID 10 (device_updater.cpp:858 uses the deviceUpdater's own eid member). EID 10 timed out on ActivateFirmware while EID 12's deviceUpdater state was corrupted by the misrouted messages. The per-ItemUpdateManager state (deviceUpdater, packageMap, dupFd, inProgressActivation, ...) is already independent, and the shared Handler<Request>/InstanceIdDb demux BMC->FD responses by (eid, instanceId), so concurrent multi-EID target updates work correctly once the responder path stops the cross-EID misrouting. Add an explicit eid != this->eid early-return that yields PLDM_FWUP_COMMAND_NOT_EXPECTED, letting AggregateUpdateManager fall through to the next manager. Fold the !deviceUpdater branch into the same early-return since it returns the same encoded response, and convert the placement-new calls to std::start_lifetime_as<> to match the rest of the codebase. Tested on nvl32-obmc: - Full bundle multipart update. - Single target update. - Back to back single-target updates. - Full bundle update followed by a target update (previously flooded the journal with "invalid state when updating progress" and served data from the stale bundle DeviceUpdater; now routed correctly). - Target update on a second PLDM device while an update on another device is in progress: both complete successfully. - Target update on the same device while its update is in progress: rejected as expected. Signed-off-by: Dhruv Rathi <rathidhruv04@gmail.com> Change-Id: I390c54c82fc6405de37a06af6a8d0e80d31735d3
PLDM (Platform Level Data Model) is a key component of the OpenBMC project, providing a standardized data model and message formats for various platform management functionalities. It defines a method to manage, monitor, and control the firmware and hardware of a system.
The OpenBMC PLDM project aims to implement the specifications defined by the Distributed Management Task Force (DMTF), allowing for interoperable management interfaces across different hardware and firmware components.
To build and run PLDM, you need the following dependencies:
MesonNinjaAlternatively, source an OpenBMC ARM/x86 SDK.
To build the PLDM project, follow these steps:
meson setup build && meson compile -C build
The simplest way of running the tests is as described by the meson man page:
meson test -C build
Alternatively, tests can be run in the OpenBMC CI docker container using these steps.
pldm daemon accepts a command line argument --verbose or --v or -v to enable the daemon to run in verbose mode. It can be done via adding this option to the environment file that pldm service consumes.
echo 'PLDMD_ARGS="--verbose"' > /etc/default/pldmd systemctl restart pldmd
rm /etc/default/pldmd systemctl restart pldmd
For complete documentation on the functionality and usage of this repository, please refer to the docs folder.