[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230213111152.5ecf734b@jacob-builder>
Date: Mon, 13 Feb 2023 11:11:52 -0800
From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
To: Jason Gunthorpe <jgg@...dia.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>,
jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH 2/2] iommu/ioasid: Remove custom IOASID allocator
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). So this is not the "multiple pasid spaces"
case here, right?
As I replied to Jean as well, we could use the ioasid_set to separate SVA
and DMA API PASIDs.
Thanks,
Jacob
Powered by blists - more mailing lists