[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+qSj+xLkqhF7ZE3@nvidia.com>
Date: Mon, 13 Feb 2023 15:42:07 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc: Jean-Philippe Brucker <jean-philippe@...aro.org>,
LKML <linux-kernel@...r.kernel.org>, iommu@...ts.linux.dev,
Lu Baolu <baolu.lu@...ux.intel.com>,
Joerg Roedel <joro@...tes.org>,
Jean-Philippe Brucker <jean-philippe@...aro.com>,
Robin Murphy <robin.murphy@....com>,
David Woodhouse <dwmw2@...radead.org>,
Raj Ashok <ashok.raj@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>, Yi Liu <yi.l.liu@...el.com>
Subject: Re: [PATCH 2/2] iommu/ioasid: Remove custom IOASID allocator
On Mon, Feb 13, 2023 at 11:11:52AM -0800, Jacob Pan wrote:
> Hi Jason,
>
> On Mon, 13 Feb 2023 12:24:15 -0400, Jason Gunthorpe <jgg@...dia.com> wrote:
>
> > > We could also merge ioasid.c into iommu-sva.c at this point, since I
> > > haven't seen any interest for having multiple IOASID sets on Arm, but
> > > I'm not sure what the current plan is for vSVA on x86.
> >
> > Once the customer allocator is removed this is bascially a thin
> > wrapper around xarray
> >
> > So anything that needs multiple pasid spaces should just create it on
> > its own directly with xarray
> >
> Just wanted to double check that for devices on VT-d platforms that support
> both SVA and DMA API with PASID, we will still need a single global pasid
> space (due to IOTLB tagging).
Each driver chooses the PASID allocator it wants to use.
If the driver uses SVA then the driver must select the global SVA
allocator. If the driver needs PASID's for other purposes then it must
get them from the SVA allocator too.
> As I replied to Jean as well, we could use the ioasid_set to separate SVA
> and DMA API PASIDs.
That doesn't make sense to me..
Jason
Powered by blists - more mailing lists