<div dir="ltr">Hi Jason,<div><br></div><div>I guess I missed this conversation when it first started. We have some interest in getting PCIe metadata forwarded to the BMC. I kind of assumed that the only way was to use a side-band channel, but I getting it through PECI would be very interesting.</div><div><br></div><div>Nancy should have a better idea what we'd be looking for.</div><div><br></div><div>- Richard</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 4:38 PM Bills, Jason M <<a href="mailto:jason.m.bills@linux.intel.com">jason.m.bills@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Brad,<br>
<br>
On 4/30/2020 2:14 PM, Bills, Jason M wrote:<br>
> <br>
> <br>
> On 12/19/2019 12:45 AM, Neeraj Ladkani wrote:<br>
>> It depends on requirements like in our use case, our PCIe devices are <br>
>> fixed so we can preprogram a array in JSON file to include all PCI <br>
>> functions from a device but for someone else for example OEM who is <br>
>> selling the servers, it not possible to predict all PCI device can be <br>
>> connected on PCIe slot so we can let system firmware send this <br>
>> information or do RdPCIRd via PECI.<br>
> <br>
> Sorry for not replying earlier.  I had some legal questions that I was <br>
> waiting to be resolved.<br>
> <br>
> Intel has a downstream solution that uses PECI to get the PCIe <br>
> information onto D-Bus which is then published to Redfish.  I can now <br>
> share what we have upstream if there is interest.<br>
> <br>
> If so, I guess I'd need a new 'peci-pcie' repo to check into?<br>
Not sure if anyone saw this or if there is just no interest. :)<br>
<br>
Could you please create a peci-pcie repo for this application?<br>
<br>
Thanks!<br>
-Jason<br>
<br>
> <br>
> Thanks,<br>
> -Jason><br>
>> I am not aware of any standards on "Implementation". I have seen <br>
>> typical implementations where system firmware sends post PCIe data ( <br>
>> exact schema) to BMC using redfish and BMC produces this data over <br>
>> redfish ( just act like passthrough).<br>
>><br>
>> Neeraj<br>
>><br>
>> -----Original Message-----<br>
>> From: Brad Bishop <<a href="mailto:bradleyb@fuzziesquirrel.com" target="_blank">bradleyb@fuzziesquirrel.com</a>><br>
>> Sent: Wednesday, December 18, 2019 4:35 AM<br>
>> To: Neeraj Ladkani <<a href="mailto:neladk@microsoft.com" target="_blank">neladk@microsoft.com</a>><br>
>> Cc: OpenBMC Maillist <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>><br>
>> Subject: Re: [EXTERNAL] how to get pci config space<br>
>><br>
>> Thanks Neeraj<br>
>><br>
>>> On Dec 18, 2019, at 2:18 AM, Neeraj Ladkani <<a href="mailto:neladk@microsoft.com" target="_blank">neladk@microsoft.com</a>> <br>
>>> wrote:<br>
>>><br>
>>> IMO, we only need DeviceID and VendorID fields from PCIe Config space<br>
>><br>
>> This would probably meet my need to dynamically tune fan control <br>
>> parameters.  Is it possible to populate instances of the pciedevice <br>
>> schema based on devid and vendorid alone?<br>
>><br>
>>> and we can let system firmware send this information during boot<br>
>><br>
>> This is how it works on Power systems before OpenBMC, but we have a <br>
>> custom protocol with a proprietary implementation.  The purpose of my <br>
>> note was to find out if there are typical implementations or even <br>
>> standards out there for doing this.<br>
>><br>
>>> or preprogram the information to BMC using EntityManager.<br>
>><br>
>> Can you elaborate on how this would work?  Given the number of pcie <br>
>> devices out there this seems like it would be hard to do it this way <br>
>> without a huge database of some kind on the bmc?<br>
>><br>
>>> Regarding BMC-CPU(via PECI), BMC needs to send PECI command to CPU. <br>
>>> CPU should support RdPCICfg as supported PECI command and thus <br>
>>> respond with data.<br>
>><br>
>> Ok - that sounds like its all in hardware.  But above it sounded like <br>
>> you suggest we skip RdPCICfg and instead let system firmware push this <br>
>> information down to the BMC - do I have it right?  If so why do you <br>
>> prefer that mechanism?<br>
>><br>
>> thx!<br>
>><br>
>> -brad<br>
>><br>
</blockquote></div>