> On May 13, 2025, at 3:10 AM, Daniel P. Berrangé <berra...@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é <berra...@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/docs/specs/fw_cfg.rst#L279
>>
>> 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.
