Hi, > > Strictly speaking you don't care that much about the size of the mmio > > window, but where it gets placed. Moving it to the end of the vcpu > > address space is what breaks your use case in case the iommu address > > space happens to be too small for that. > Right, the crux of the problem is indeed the placement of the window > and not the size. Given this, do you see any problem if the mmio window > were to be placed at the lower end of the address space?
That might still not work because OVMF scales the window size with the address space. > Or, do you think > ensuring that PhysMemAddressWidth = <IOMMU address width> > automatically via Qemu/OVMF like Laszlo suggested is a better solution > for this problem? The best temporary stop gap IMHO is using -cpu host-phys-bits=on,host-phys-bits-limit=<iommu-address-bits> Side note: The qemu master branch has a precompiled seabios version which also does iommu window scaling and will need the same treatment. How to solve that long-term should be discussed on the qemu-devel list. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110835): https://edk2.groups.io/g/devel/message/110835 Mute This Topic: https://groups.io/mt/102359124/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
