Re: [PATCH RESEND 0/6] Add support for configuring PCI high memory MMIO size

On May 13, 2025, at 3:10 AM, Daniel P. Berrangé <berrange(a)redhat.com&gt; 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(a)redhat.com&gt; 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/7be29f2f1a3f5b037d27eedbd5df9f441e8c8c1... > > 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.