Redfish PCIe Resources

Author: Jason Bills, jmbills

Other contributors: Ed Tanous

Created: April 3, 2019

Problem Description

Redfish has resources that describe PCIe devices and functions available on a system. It would be useful to provide these resources to users out-of-band over Redfish from OpenBMC.

Background and References

The Redfish PCIe resources are here:

PCIeSlots

PCIeDevice

PCIeFunction

Requirements

This feature is intended to meet the Redfish requirements for the PCIe resources above to provide useful system configuration information to system administrators and operators.

Proposed Design

The proposed implementation will follow the standard D-Bus producer-consumer model used in OpenBMC. The producer will provide the required PCIe values read from hardware. The consumer will retrieve and parse the D-Bus data to provide the Redfish PCIe resources.

The proposed D-Bus interface can be found here: https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/19768

The proposed producer will be a new D-Bus daemon that will be responsible for gathering and caching PCIe hardware data and maintaining the D-Bus interfaces and properties. The actual hardware mechanism that is used to gather the PCIe hardware data will vary.

For example, on systems that the BMC has access to the host PCI configuration space, it can directly read the required registers. On systems without access to the host PCI configuration space, an entity such as the BIOS or OS can gather the required data and send it to the PCIe daemon through IPMI, etc.

When reading hardware directly, the PCIe daemon must be aware of power state changes and any BIOS timing requirements, so it can check for hardware changes, update its cache, and make the necessary changes to the D-Bus properties. This will allow a user to retrieve the latest PCIe resource data as of the last system boot even if it is powered off.

bmcweb will be the consumer. It will be responsible for retrieving the Redfish PCIe resource data from the D-Bus properties and providing it to the user.

Alternatives Considered

None.

Impacts

Possible performance impact on the hardware-scanning and D-Bus updates. The piece that implements hardware scanning should use mechanisms, such as caching of the hardware configuration, to minimize the scanning time and updates to D-Bus properties.

Testing

This can be tested using the Redfish Service Validator.