[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191023160152.07305918@jacob-builder>
Date: Wed, 23 Oct 2019 16:01:52 -0700
From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
To: Lu Baolu <baolu.lu@...ux.intel.com>
Cc: "Raj, Ashok" <ashok.raj@...el.com>,
iommu@...ts.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
David Woodhouse <dwmw2@...radead.org>,
Alex Williamson <alex.williamson@...hat.com>,
Jean-Philippe Brucker <jean-philippe@...aro.com>,
Yi Liu <yi.l.liu@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
Christoph Hellwig <hch@...radead.org>,
Jonathan Cameron <jic23@...nel.org>,
Eric Auger <eric.auger@...hat.com>,
jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH v6 02/10] iommu/vt-d: Add custom allocator for IOASID
On Wed, 23 Oct 2019 10:21:51 +0800
Lu Baolu <baolu.lu@...ux.intel.com> wrote:
> >> +#ifdef CONFIG_INTEL_IOMMU_SVM
> >
> > Maybe move them to intel-svm.c instead? that's where the bulk
> > of the svm support is?
>
> I think this is a generic PASID allocator for guest IOMMU although
> vSVA is currently the only consumer. Instead of making it SVM
> specific, I'd like to suggest moving it to intel-pasid.c and replace
> the @svm parameter with a void * one in intel_ioasid_free().
make sense to use void*, no need to tie that to svm bind data type.
In terms of location, perhaps we can move if we have more consumers of
custom allocator?
Powered by blists - more mailing lists