[Intel-gfx] [PATCH v4 2/9] vfio-iommufd: Create iommufd_access for noiommu devices
Alex Williamson
alex.williamson at redhat.com
Wed May 3 22:49:16 UTC 2023
On Wed, 3 May 2023 16:41:52 -0300
Jason Gunthorpe <jgg at nvidia.com> wrote:
> > > My general idea to complete the no-iommu feature is to add a new IOCTL
> > > to VFIO that is 'pin iova and return dma addr' that no-iommu userspace
> > > would call instead of trying to abuse mlock and /proc/ to do it. That
> > > ioctl would use the IOAS attached to the access just like a mdev would
> > > do, so it has a real IOVA, but it is not a mdev.
> >
> > This new ioctl may be IOMMUFD ioctl since its input is the IOAS and
> > addr, nothing related to the device. Is it?
>
> No, definately a VFIO special ioctl for VFIO no-iommu mode.
This seems like brushing off the dirty work to vfio. Userspace drivers
relying on no-iommu are in pretty questionable territory already, do we
care if they don't have a good means to pin pages and derive the DMA
address of those pinned pages? As I noted earlier, I'm really not
interested in expanding no-iommu, it's less important now than when it
was added (we have vIOMMUs in VMs now and more platforms with IOMMUs)
and we shouldn't be encouraging its use by further developing the
interface. Thanks,
Alex
More information about the Intel-gfx
mailing list