> On May 9, 2025, at 9:59 AM, Daniel P. Berrangé <berra...@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)?
