> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, February 1, 2023 10:56 PM > > 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. > Make sense.
