On Wed, Feb 01, 2023 at 03:14:03AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Monday, January 30, 2023 9:33 PM > > > > On Sun, Jan 29, 2023 at 08:11:48AM +0000, Tian, Kevin wrote: > > > > > " I'd also question sprd-iommu, which hardly has a generally-useful > > > domain size, and has only just recently gained the ability to unmap > > > anything successfully." > > > > So long as it has a correct kernel API and exposes the right (small) > > aperture then it is OK. > > > > The device will not be useful for qemu, but it would run some dpdk > > configurations just fine. > > I still didn't get the restriction here. Can you elaborate why it works > with dpdk but not qemu? dpdk needs like, say, 64M of aperture and doesn't care what the IOVAs are qemu needs the entire guest memory of aperture and must have IOVAs that are 1:1 with the GPA. So aperture size and location can exclude qemu > Can qemu verify this restriction via existing path or need new uAPI > flag to communicate? It already happens, the aperture/etc is convayed to qemu through IOMMUFD_CMD_IOAS_IOVA_RANGES and if qemu cannot get the IOVA's it needs to create the guest it should fail. Jason
