1# Redfish PCIe Resources 2 3Author: Jason Bills, jmbills 4 5Other contributors: Ed Tanous 6 7Created: April 3, 2019 8 9## Problem Description 10 11Redfish has resources that describe PCIe devices and functions available on a 12system. It would be useful to provide these resources to users out-of-band over 13Redfish from OpenBMC. 14 15## Background and References 16 17The Redfish PCIe resources are here: 18 19[PCIeSlots](https://redfish.dmtf.org/schemas/PCIeSlots_v1.xml) 20 21[PCIeDevice](https://redfish.dmtf.org/schemas/PCIeDevice_v1.xml) 22 23[PCIeFunction](https://redfish.dmtf.org/schemas/PCIeFunction_v1.xml) 24 25## Requirements 26 27This feature is intended to meet the Redfish requirements for the PCIe resources 28above to provide useful system configuration information to system 29administrators and operators. 30 31## Proposed Design 32 33The proposed implementation will follow the standard D-Bus producer-consumer 34model used in OpenBMC. The producer will provide the required PCIe values read 35from hardware. The consumer will retrieve and parse the D-Bus data to provide 36the Redfish PCIe resources. 37 38The proposed D-Bus interface can be found here: 39https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/19768 40 41The proposed producer will be a new D-Bus daemon that will be responsible for 42gathering and caching PCIe hardware data and maintaining the D-Bus interfaces 43and properties. The actual hardware mechanism that is used to gather the PCIe 44hardware data will vary. 45 46For example, on systems that the BMC has access to the host PCI configuration 47space, it can directly read the required registers. On systems without access to 48the host PCI configuration space, an entity such as the BIOS or OS can gather 49the required data and send it to the PCIe daemon through IPMI, etc. 50 51When reading hardware directly, the PCIe daemon must be aware of power state 52changes and any BIOS timing requirements, so it can check for hardware changes, 53update its cache, and make the necessary changes to the D-Bus properties. This 54will allow a user to retrieve the latest PCIe resource data as of the last 55system boot even if it is powered off. 56 57bmcweb will be the consumer. It will be responsible for retrieving the Redfish 58PCIe resource data from the D-Bus properties and providing it to the user. 59 60## Alternatives Considered 61 62None. 63 64## Impacts 65 66Possible performance impact on the hardware-scanning and D-Bus updates. The 67piece that implements hardware scanning should use mechanisms, such as caching 68of the hardware configuration, to minimize the scanning time and updates to 69D-Bus properties. 70 71## Testing 72 73This can be tested using the Redfish Service Validator. 74