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