[EXTERNAL] how to get pci config space

[Neeraj Ladkani]

It depends on requirements like in our use case, our PCIe devices are fixed so we can preprogram a array in JSON file to include all PCI functions from a device but for someone else for example OEM who is selling the servers, it not possible to predict all PCI device can be connected on PCIe slot so we can let system firmware send this information or do RdPCIRd via PECI. 

I am not aware of any standards on "Implementation". I have seen typical implementations where system firmware sends post PCIe data ( exact schema) to BMC using redfish and BMC produces this data over redfish ( just act like passthrough). 

Neeraj

-----Original Message-----
From: Brad Bishop <bradleyb at fuzziesquirrel.com> 
Sent: Wednesday, December 18, 2019 4:35 AM
To: Neeraj Ladkani <neladk at microsoft.com>
Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: [EXTERNAL] how to get pci config space

Thanks Neeraj

> On Dec 18, 2019, at 2:18 AM, Neeraj Ladkani <neladk at microsoft.com> wrote:
> 
> IMO, we only need DeviceID and VendorID fields from PCIe Config space

This would probably meet my need to dynamically tune fan control parameters.  Is it possible to populate instances of the pciedevice schema based on devid and vendorid alone?

> and we can let system firmware send this information during boot

This is how it works on Power systems before OpenBMC, but we have a custom protocol with a proprietary implementation.  The purpose of my note was to find out if there are typical implementations or even standards out there for doing this.

> or preprogram the information to BMC using EntityManager. 

Can you elaborate on how this would work?  Given the number of pcie devices out there this seems like it would be hard to do it this way without a huge database of some kind on the bmc?

> Regarding BMC-CPU(via PECI), BMC needs to send PECI command to CPU. CPU should support RdPCICfg as supported PECI command and thus respond with data.

Ok - that sounds like its all in hardware.  But above it sounded like you suggest we skip RdPCICfg and instead let system firmware push this information down to the BMC - do I have it right?  If so why do you prefer that mechanism?

thx!

-brad