[EXTERNAL] how to get pci config space

[Bills, Jason M]

On 12/19/2019 12:45 AM, Neeraj Ladkani wrote:
> 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.

Sorry for not replying earlier.  I had some legal questions that I was 
waiting to be resolved.

Intel has a downstream solution that uses PECI to get the PCIe 
information onto D-Bus which is then published to Redfish.  I can now 
share what we have upstream if there is interest.

If so, I guess I'd need a new 'peci-pcie' repo to check into?

Thanks,
-Jason>
> 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
>