On May 13, 2025, at 3:10 AM, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Mon, May 12, 2025 at 07:33:37PM +0000, Matt Ochs wrote:
On May 12, 2025, at 5:19 AM, Daniel P. Berrangé <berrange@redhat.com> wrote: On Fri, May 09, 2025 at 07:29:04PM +0000, Matt Ochs wrote:
Would it make sense to just use the existing pcihole64 since [I think] it more or less represents the same concept (setting 64bit MMIO window)?
I'm not sure. I've been struggling to reproduce an effect wit hseting the existing -global q35-pcihost.pci-hole64-size=1048576K settings on x86, and also wondering how it interacts with the previously mentioned -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=262144
Possibly the former only works with SeaBIOS, and the latter only works with EDK2, but I've not figured out how to prove this.
The qemu docs mention opt/ovmf is specifically for OVMF firmware: https://github.com/qemu/qemu/blob/7be29f2f1a3f5b037d27eedbd5df9f441e8c8c16/d...
The pcihole64 setting can be used with OVMF (see below) and with SEABIOS: https://github.com/libvirt/libvirt/blob/master/docs/formatdomain.rst (see pcihole64)
The X-PciMmio64Mb parameter isn't directly supported in libvirt IIUC. The libvirt XML would need to directly pass qemu command line arguments to use it.
I'm wondering what the semantic difference is between setting the pcihole64 property and the X-PciMmio64Mb fwcfg, in the context of OVMF.
The fact that both exist, suggests that there is a meaningful difference, which in turn would mean libvirt might need separate XML attributes for each, which in turn influences how we might choose to design the aarch64 solution.
AFAICT, I think these are the key points between the two… - pcihole64 is a QEMU property It tells QEMU how much address space to reserve for 64-bit PCI MMIO. It is about the host’s reservation and what is exposed to the guest. - X-PciMmio64Mb is an OVMF/firmware override It tells OVMF to use a specific size for the MMIO64 window, regardless of what QEMU might have reserved or exposed by default. Moreover, as indicated by the X- prefix, this is an “experimental” option that isn’t widely documented and used as a workaround for situations where the default window sizing logic that is present in OVMF is insufficient. Since highmem-mmio-size is also a QEMU property that deals with host-side reservation for the MMIO64 window, it seems more in line with pcihole64.