lkml.org 
[lkml]   [2020]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v5 05/15] vfio: Add PASID allocation/free support
Date
Hi Eric,

> From: Auger Eric <eric.auger@redhat.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


\
 
 \ /
  Last update: 2020-07-20 10:50    [W:0.064 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site