On 06/17/16 13:20, Gerd Hoffmann wrote: > Hi, > >>> Not sure whenever qemu adds some extra space for hotplug to the 64bit >>> hole and if so how it calculates the size then. But the guest os should >>> stick to those ranges when configuring hotplugged devices. > >> currently firmware would assign 64-bit BARs after reserved-memory-end >> (not sure about ovmf though) > > Ah, right, reserved-memory-end is checked too if present. Both seabios > and ovmf should do that.
OVMF does that, yes. > >> but QEMU on ACPI side will add 64-bit _CRS only >> for firmware mapped devices (i.e. no space reserved for hotplug). > > Yes. Tested meanwhile, looks like this (seabios): > > 100000000-17fffffff : System RAM > 180000000-1c1ffffff : PCI Bus 0000:00 > 180000000-1bfffffff : 0000:00:0f.0 > 1c0000000-1c07fffff : PCI Bus 0000:04 > 1c0000000-1c07fffff : 0000:04:00.0 > 1c0000000-1c07fffff : virtio-pci > 1c0800000-1c0ffffff : PCI Bus 0000:03 > 1c0800000-1c0ffffff : 0000:03:00.0 > 1c0800000-1c0ffffff : virtio-pci > 1c1000000-1c17fffff : PCI Bus 0000:02 > 1c1000000-1c17fffff : 0000:02:00.0 > 1c1000000-1c17fffff : virtio-pci > 1c1800000-1c19fffff : PCI Bus 0000:08 > 1c1a00000-1c1bfffff : PCI Bus 0000:07 > 1c1c00000-1c1dfffff : PCI Bus 0000:06 > 1c1e00000-1c1ffffff : PCI Bus 0000:05 (This is from /proc/iomem in the guest, right? A note about this later.) > seabios assigns a 2M memory window to pci bridges (which support > hotplug) even in case no device is connected, so there is some space for > hotplug because of that. > > /me should try the same with ovmf ... The generic PCI bus driver in edk2 (PciBusDxe), which is built into OVMF, does not allocate IO and/or MMIO for a bridge if there are zero devices behind the bridge that consume that kind of resource. I actually consider this a feature, not a bug, because it helps avoid the exhaustion of the limited IO port space. In any case, /proc/iomem is not a good tool for investigating resources assigned by the firmware. Linux is stubborn and will *itself* allocate IO port ranges for bridges, for example, when OVMF -- justifiedly, see above -- did no such thing. Marcel suggested to prevent this with various bridge registers, and Paolo suggested to modify Linux's behavior. Either way, what you see in /proc/iomem is not the unadulterated effect of the firmware. In OVMF's case, the resource map for every bridge / device can be seen in the OVMF debug log, searching for the string "resource map" (case-insensitively). Regarding PCIe hotplug, it seemed to work under OVMF, after we fixed <https://github.com/tianocore/edk2/issues/32> with Marcel's crucial help. OVMF inherits the PcdPciBusHotplugDeviceSupport=TRUE build-time feature flag from "MdeModulePkg/MdeModulePkg.dec": ## Indicates if PciBus driver supports the hot plug device.<BR><BR> # TRUE - PciBus driver supports the hot plug device.<BR> # FALSE - PciBus driver doesn't support the hot plug device.<BR> # @Prompt Enable PciBus hot plug device support. gEfiMdeModulePkgTokenSpaceGuid.PcdPciBusHotplugDeviceSupport|TRUE|BOOLEAN|0x0001003d I've never checked how exactly that knob affects PciBusDxe, but it's TRUE in OVMF. Thanks Laszlo