Re: [PATCH RESEND 0/6] Add support for configuring PCI high memory MMIO size
On May 9, 2025, at 9:59 AM, Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
On Fri, Apr 11, 2025 at 08:40:54AM -0700, Matthew R. Ochs via Devel wrote:
> Resending: Series has been re-based over latest upstream.
>
> This patch series adds support for configuring the PCI high memory MMIO
> window size for aarch64 virt machine types. This feature has been merged
> into the QEMU upstream master branch [1] and will be available in QEMU 10.0.
> It allows users to configure the size of the high memory MMIO window above
> 4GB, which is particularly useful for systems with large amounts of PCI
> memory requirements.
>
> The feature is exposed through the domain XML as a new PCI feature:
> <features>
> <pci>
> <highmem-mmio-size unit='G'>512</highmem-mmio-size>
> </pci>
> </features>
As a schema design comment. IIUC, the MMIO size we're configuring
is conceptually a characteristic associated with the PCI(e) host
and the memory layout it defines for PCI(e) devices to use.
Correct.
Checking through our schema I find we already have support
for
<controller type='pci' index='0' model='pci-root'>
<pcihole64 unit='KiB'>1048576</pcihole64>
</controller>
this makes me think that we should model this new attribute
in a similar way, eg so we can support:
<controller type='pci' index='0' model='pci-root'>
<pcihole64 unit='KiB'>1048576</pcihole64>
<pcimmio64 unit='TiB'>2</pcimmio64>
</controller>
(pci-root or pcie-root are interchangable).
This 'pcimmio64' value can then be mapped to whatever hypervisor
or architecture specific setting is appropriate, avoiding exposing
the QEMU arm 'highmem-mmio-size' naming convention.
Thanks for the feedback, this sounds like a better approach.
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)?
Or perhaps that would be too messy or x86-centric and it’s better to go
with what you proposed (pcimmio64)?