RE: [PATCH 1/4] iommu: Add a broken_unmanaged_domain flag in iommu_ops

[Tian, Kevin]

> 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.