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