[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211018174226.GP2744544@nvidia.com>
Date: Mon, 18 Oct 2021 14:42:26 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Liu Yi L <yi.l.liu@...el.com>, alex.williamson@...hat.com,
hch@....de, jasowang@...hat.com, joro@...tes.org,
jean-philippe@...aro.org, kevin.tian@...el.com, parav@...lanox.com,
lkml@...ux.net, pbonzini@...hat.com, lushenming@...wei.com,
eric.auger@...hat.com, corbet@....net, ashok.raj@...el.com,
yi.l.liu@...ux.intel.com, jun.j.tian@...el.com, hao.wu@...el.com,
dave.jiang@...el.com, jacob.jun.pan@...ux.intel.com,
kwankhede@...dia.com, robin.murphy@....com, kvm@...r.kernel.org,
iommu@...ts.linux-foundation.org, dwmw2@...radead.org,
linux-kernel@...r.kernel.org, baolu.lu@...ux.intel.com,
nicolinc@...dia.com
Subject: Re: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
On Mon, Oct 18, 2021 at 02:50:54PM +1100, David Gibson wrote:
> Hrm... which makes me think... if we allow this for the common
> kernel-managed case, do we even need to have capcity in the high-level
> interface for reporting IO holes? If the kernel can choose a non-zero
> base, it could just choose on x86 to place it's advertised window
> above the IO hole.
If the high level interface is like dma_map() then, no it doesn't need
the ability to report holes. Kernel would find and return the IOVA
from dma_map not accept it in.
Since dma_map is a well proven model I'm inclined to model the
simplied interface after it..
That said, if we have some ioctl 'query iova ranges' I would expect it
to work on an IOAS created by the simplified interface too.
Jason
Powered by blists - more mailing lists