[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRJAHYh5j6Ni6JCl@infradead.org>
Date: Tue, 10 Aug 2021 10:00:13 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Alex Williamson <alex.williamson@...hat.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
peterx@...hat.com
Subject: Re: [PATCH 4/7] vfio,vfio-pci: Add vma to pfn callback
On Thu, Aug 05, 2021 at 10:01:46PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 05, 2021 at 11:07:47AM -0600, Alex Williamson wrote:
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index 1e4fc69fee7d..42ca93be152a 100644
> > +++ b/drivers/vfio/vfio.c
> > @@ -875,6 +875,22 @@ struct vfio_device *vfio_device_get_from_dev(struct device *dev)
> > }
> > EXPORT_SYMBOL_GPL(vfio_device_get_from_dev);
> >
> > +static const struct file_operations vfio_device_fops;
> > +
> > +int vfio_device_vma_to_pfn(struct vfio_device *device,
> > + struct vm_area_struct *vma, unsigned long *pfn)
>
> A comment here describing the locking conditions the caller must meet
> would be a good addition.. It looks like this can only work under the
> i_mmap_lock and the returned pfn can only be taken outside that lock
> if it is placed in a VMA
>
> Maybe this is not a great API then? Should it be 'populate vma' and
> call io_remap_pfn_range under the op?
Yes, I think that would be a better API.
Powered by blists - more mailing lists