On 06/30/16 16:48, Brian J. Johnson wrote:
> On 06/30/2016 09:35 AM, Laszlo Ersek wrote:
>> On 06/30/16 16:24, Brian J. Johnson wrote:
>>> On 06/30/2016 08:07 AM, Laszlo Ersek wrote:
>>
>>>> - Does PCIe hotplug into downstream ports work with any (phys) firmware
>>>>     forked from edk2? Brian, Samer, do you guys have experience with
>>>> this?
>>>
>>> Yes, we support it on our UV server line.  Physically, hotplug is only
>>> possible in expansion chassis designed for that purpose.  (That's not a
>>> problem with virtual machines, of course.)  But we've had to do quite a
>>> bit of work on the host bridge driver to allowing scaling to the sizes
>>> of systems we support (hundreds of sockets and PCIe slots, dozens of TB
>>> of RAM), including reserving resources for hotplug only in the specific
>>> cases where it's possible.
>>
>> Thanks a lot for your answer! Could you perhaps check for me if your
>> platform firmware implements EFI_PCI_HOT_PLUG_INIT_PROTOCOL, highlighted
>> by Andrew?
> 
> 
> Yes, we do.  We have a customized implementation of this protocol which
> provides padding values optimized for the expansion chassis we support.

Awesome. That's what I'm looking at in the PI spec right now.

I'm being led to believe that I won't need to return any
EFI_HPC_LOCATIONs from GetRootHpcList(), and correspondingly I can stub
out InitializeRootHpc() as well. The PI spec allows this:

    * As stated above, root HPCs may require firmware initialization.
      PI Architecture firmware must be capable of supporting root HPCs
      that are initialized by hardware and do not require any firmware
      initialization.

[...]

    Scan all the devices in the specified bus range and the specified
    segment, one bus at a time. If the device is a PCI-to-PCI bridge,
    update the bus numbers and program the bus number registers in the
    PCI-to-PCI bridge hardware. If the device path of a device matches
    that of a root HPC and it is not a PCI-to-CardBus bridge, it must
    be initialized by calling
    EFI_PCI_HOT_PLUG_INIT_PROTOCOL.InitializeRootHpc() before the bus it
    controls can be fully enumerated.

[...]

    Root HPC

        These HPCs must be initialized by calling InitializeRootHpc()
        during the enumeration process. These HPCs will also require
        resource padding. The platform code must have a priori
        knowledge of these devices and must know how to initialize
        them. There may not be any way to access their PCI
        configuration space before the PCI enumerator programs all the
        upstream bridges and thus enables the path to these devices.

The recursive enumeration works just fine already. On QEMU's virtual
hardware, there doesn't seem to be any need for this kind of
initialization. It's the resource padding bit that I have to figure out.

Thank you!
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to