Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set

[Laszlo Ersek]

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