[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR11MB14353C2D9929384A45E8B285C37B0@DM5PR11MB1435.namprd11.prod.outlook.com>
Date: Mon, 20 Jul 2020 08:49:41 +0000
From: "Liu, Yi L" <yi.l.liu@...el.com>
To: Auger Eric <eric.auger@...hat.com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
"joro@...tes.org" <joro@...tes.org>
CC: "Tian, Kevin" <kevin.tian@...el.com>,
"jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Tian, Jun J" <jun.j.tian@...el.com>,
"Sun, Yi Y" <yi.y.sun@...el.com>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"peterx@...hat.com" <peterx@...hat.com>,
"Wu, Hao" <hao.wu@...el.com>,
"stefanha@...il.com" <stefanha@...il.com>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 05/15] vfio: Add PASID allocation/free support
Hi Eric,
> From: Auger Eric <eric.auger@...hat.com>
> Sent: Monday, July 20, 2020 4:26 PM
[...]
> >>> +int vfio_pasid_alloc(struct vfio_mm *vmm, int min, int max) {
> >>> + ioasid_t pasid;
> >>> + struct vfio_pasid *vid;
> >>> +
> >>> + pasid = ioasid_alloc(vmm->ioasid_sid, min, max, NULL);
> >>> + if (pasid == INVALID_IOASID)
> >>> + return -ENOSPC;
> >>> +
> >>> + vid = kzalloc(sizeof(*vid), GFP_KERNEL);
> >>> + if (!vid) {
> >>> + ioasid_free(pasid);
> >>> + return -ENOMEM;
> >>> + }
> >>> +
> >>> + vid->pasid = pasid;
> >>> +
> >>> + mutex_lock(&vmm->pasid_lock);
> >>> + vfio_link_pasid(vmm, vid);
> >>> + mutex_unlock(&vmm->pasid_lock);
> >>> +
> >>> + return pasid;
> >>> +}
> >> I am not totally convinced by your previous reply on EXPORT_SYMBOL_GP()
> >> irrelevance in this patch. But well ;-)
> >
> > I recalled my memory, I think it's made per a comment from Chris.
> > I guess it may make sense to export symbols together with the exact
> > driver user of it in this patch as well :-) but maybe I misunderstood
> > him. if yes, I may add the symbol export back in this patch.
> >
> > https://lore.kernel.org/linux-iommu/20200331075331.GA26583@infradead.org/#t
> OK I don't know the best practice here. Anyway there is no caller at
> this stage either. I think you may describe in the commit message the
> vfio_iommu_type1 will be the eventual user of the exported functions in
> this module, what are the exact exported functions here. You may also
> explain the motivation behind creating a separate module.
got it. will add it.
Regards,
Yi Liu
Powered by blists - more mailing lists