On 06/30/2016 04:07 PM, Laszlo Ersek wrote:
Hi,
does anyone on this list have experience with $SUBJECT, using physical
UEFI firmware derived from edk2?
The problem we're seeing with OVMF is the following: PCIe hotplug works
with PCIe root ports, but it doesn't work with PCIe downstream ports.
The error messages reported by both Linux and Windows guests indicate
"lack of resources" for the device being plugged.
In my understanding:
* Each PCIe downstream port qualifies as a separate bus / bridge.
* Bridges need IO and MMIO resources for themselves. When a device is
behind a bridge at boot, the device's IO and MMIO BARs are carved out
of the bridge's IO and MMIO apertures. For IO, the standard bridge
aperture size is 4096 (byte-sized) ports.
* If no device behind a bridge needs a specific type of resource (for
example, no devices behind a bridge have IO BARs), then that kind of
aperture is not necessary for the bridge either.
A special case of this is when there are no devices behind a bridge
at all. Example: PCIe downstream port empty at boot. In this case,
the bridge needs no resources at all, at boot.
* Different firmwares seem to follow different policies in the last
case (-> bridge empty at boot). SeaBIOS for example allocates the
0x1000 IO ports nonetheless. The PCI bus driver in edk2 does not: it
allocates no apertures for bridges that have no devices behind them
at boot.
This appears to be a trade-off: if the bridge remains empty for the
entire lifetime of the OS, then any IO ports that have been allocated
in advance will be in vain (wasted). However, if the aperture is not
allocated at boot, then hotplug under the bridge may not work --
resources for the device being hot-plugged cannot be allocated from
nonexistent bridge apertures.
Hi Laszlo,
I fully agree with your assessment.
From the firmware point of view it seems like a waste to allocate an IO/MEM
range for
an unused PCI/PCIe-bridge indeed. Especially IO.
But what about MEM?
Let's have a look to this special case: PCIe downstream ports on 64-bit systems.
1. PCIe spec requires devices to work correctly even without enabling their IO
BARs.
2. 64-bit Memory space is pretty large, decent CPUs support 46-bit addresses,
so even if the system uses Terabytes of RAM
and has dozens of switches we still have enough unused MEM space.
My point is we can skip assigning IO for PCIe ports but we can assign a 4K MEM
range in 64-bit memory for them
without being too greedy.
Would this be a decent trade-off *for OVMF* ?
Thanks,
Marcel
And that's what we are experiencing with OVMF.
My questions are:
- Is the above behavior of the edk2 PCI bus driver intentional?
- Does PCIe hotplug into downstream ports work with any (phys) firmware
forked from edk2? Brian, Samer, do you guys have experience with this?
- What could be the difference between root ports and downstream ports?
(Hotplug into root ports seems to work fine.) Are OSes entitled to
allocate any unused address space (MMIO and IO) right when a device is
hot-plugged into a root port?
Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
