On Fri, May 09, 2025 at 07:29:04PM +0000, Matt Ochs wrote: > > 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)?
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. I'm curious if there's a good way to identify the guest memory map impact, as I'm not finding a clear marker in 'dmesg' that correlates ? > Or perhaps that would be too messy or x86-centric and it’s better to go > with what you proposed (pcimmio64)? If the 'pcihole64' setting really is setting the MMIO64 window, then it would be preferrable to re-use the existing setting field. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
