Re: [PATCH v2 4/8] Ovmf/PlatformPei: Extend 64-bit MMIO range to fit resources

["Gerd Hoffmann" <kraxel@redhat.com>]

  hi,

> As an example, if the PcdPciMmio64Size is initialized to 0x800000000
> and the runtime calculated base address produces the value 0x800000000,
> the last 64-bit MMIO address a PCI host bridge may use would be
> 0xFFFFFFFFF. If one of the host-specified bridges defines a high
> memory window 0x1000000000 - 0x17FFFFFFFF (inclusive) it would be
> outside of the valid range defined by the Base address + PcdPciMmio64Size.
> Therefore, parsing the HardwwareInfo resource allows to notice the higher
> requirement and increase the size to 0x1000000000 so that the MMIO
> address space solicited by the host can be met and the range effectively
> extended to 0x17FFFFFFFF.

I think you can completely ignore PcdPciMmio64Size + PcdPciMmio64Base,
you only must make sure mPhysMemAddressWidth is big enough ...

Background story:

On qemu there is no reliable way to figure what the size of the physical
address space is.  The reason for that a rather long story involving
historical reasons, backward compatibility, live migration compatibility
and probably more stuff which I forgot meanwhile.  Those details don't
matter here, the key takeaway is that ovmf tries to minimize it's
physical address space needs because it just doesn't know how much it
can actually use.

PcdPciMmio64Size default is 32G, so a typical virtual machine fits into
64G address space (aka mPhysMemAddressWidth == 36), which is guaranteed
to work on x64.  This is also part of the plan ;)

With the qemu q35 machine types the firmware initializes the host
bridge, i.e. ovmf programs the host bridge to place the windows and the
mmconfig xbar according to the PcdPciMmio64Base + PcdPciMmio64Size
values ovmf figured during memory detection.

The whole logic is pretty much moot though if the location and size of
the mmio windows is dictated by the host and the guest can't change them
anyway ...

take care,
  Gerd