Hi Gerd, > > > > 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. Ok, I'll look into how this problem can be solved in Qemu and will further discuss about this issue on qemu-devel.
Thanks, Vivek > > take care, > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110900): https://edk2.groups.io/g/devel/message/110900 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] -=-=-=-=-=-=-=-=-=-=-=-
