74 lines
2.6 KiB
Markdown
74 lines
2.6 KiB
Markdown
# 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](https://redfish.dmtf.org/schemas/PCIeSlots_v1.xml)
|
|
|
|
[PCIeDevice](https://redfish.dmtf.org/schemas/PCIeDevice_v1.xml)
|
|
|
|
[PCIeFunction](https://redfish.dmtf.org/schemas/PCIeFunction_v1.xml)
|
|
|
|
## 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.
|