From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: <cohuck@redhat.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <peterx@redhat.com>
Subject: Re: [PATCH 1/3] vfio: Introduce vma ops registration and notifier
Date: Fri, 12 Feb 2021 17:20:57 -0400 [thread overview]
Message-ID: <20210212212057.GW4247@nvidia.com> (raw)
In-Reply-To: <161315805248.7320.13358719859656681660.stgit@gimli.home>
On Fri, Feb 12, 2021 at 12:27:39PM -0700, Alex Williamson wrote:
> Create an interface through vfio-core where a vfio bus driver (ex.
> vfio-pci) can register the vm_operations_struct it uses to map device
> memory, along with a set of registration callbacks. This allows
> vfio-core to expose interfaces for IOMMU backends to match a
> vm_area_struct to a bus driver and register a notifier for relavant
> changes to the device mapping. For now we define only a notifier
> action for closing the device.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> drivers/vfio/vfio.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/vfio.h | 20 ++++++++
> 2 files changed, 140 insertions(+)
>
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 38779e6fd80c..568f5e37a95f 100644
> +++ b/drivers/vfio/vfio.c
> @@ -47,6 +47,8 @@ static struct vfio {
> struct cdev group_cdev;
> dev_t group_devt;
> wait_queue_head_t release_q;
> + struct list_head vm_ops_list;
> + struct mutex vm_ops_lock;
> } vfio;
>
> struct vfio_iommu_driver {
> @@ -2354,6 +2356,121 @@ struct iommu_domain *vfio_group_iommu_domain(struct vfio_group *group)
> }
> EXPORT_SYMBOL_GPL(vfio_group_iommu_domain);
>
> +struct vfio_vma_ops {
> + const struct vm_operations_struct *vm_ops;
> + vfio_register_vma_nb_t *reg_fn;
> + vfio_unregister_vma_nb_t *unreg_fn;
> + struct list_head next;
> +};
> +
> +int vfio_register_vma_ops(const struct vm_operations_struct *vm_ops,
> + vfio_register_vma_nb_t *reg_fn,
> + vfio_unregister_vma_nb_t *unreg_fn)
This just feels a little bit too complicated
I've recently learned from Daniel that we can use the address_space
machinery to drive the zap_vma_ptes() via unmap_mapping_range(). This
technique replaces all the open, close and vma_list logic in vfio_pci
If we don't need open anymore, we could do something like this:
static const struct vm_operations_struct vfio_pci_mmap_ops = {
.open = vfio_pfn_open, // implemented in vfio.c
.close = vfio_pfn_close,
.fault = vfio_pci_mmap_fault,
};
Then we could code the function needed:
struct vfio_pfn_range_handle
{
struct kref kref;
struct vfio_device *vfio;
struct notifier_block invalidation_cb;
unsigned int flags;
}
struct vfio_pfn_range_handle *get_pfn_range(struct vm_area_struct *vma)
{
struct vfio_pfn_range_handle *handle;
if (vma->ops->open != vfio_pfn_open)
return NULL;
handle = vma->vm_private_data;
if (test_bit(handle->flags, DMA_STOPPED)
return NULL;
kref_get(&handle->kref);
return handle;
}
Where the common open/close only kref inc/dec the kref and all 'vfio'
VMAs always have a pointer to the same vfio_pfn_range_handle in their
private_data.
The vm_pgoff is already pointing at the physical pfn, so every part of
the system can get the information it needs fairly trivially.
Some stop access function is pretty simple looking
void stop_access(struct vfio_pfn_range_handle *handle)
{
set_bit(handle->flags, DMA_STOPPED);
unmap_mapping_range(handle->vfio->[..]->inode, 0, max, false);
srcu_notifier_call_chain(handle->invalidation_cb, VFIO_VMA_NOTIFY_CLOSE, NULL);
}
(well, have to sort out the locking some more, but that is the
general idea)
I think that would remove alot of the code added here and acts a lot
closer to how a someday dmabuf could act.
Also, this will need to update the nvlink vmops as well
Jason
next prev parent reply other threads:[~2021-02-12 21:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-12 19:27 [PATCH 0/3] vfio: Device memory DMA mapping improvements Alex Williamson
2021-02-12 19:27 ` [PATCH 1/3] vfio: Introduce vma ops registration and notifier Alex Williamson
2021-02-12 21:20 ` Jason Gunthorpe [this message]
2021-02-18 1:12 ` Jason Gunthorpe
2021-02-18 21:56 ` Alex Williamson
2021-02-18 23:04 ` Jason Gunthorpe
2021-02-19 22:02 ` Alex Williamson
2021-02-12 19:27 ` [PATCH 2/3] vfio/pci: Implement vm_ops registration Alex Williamson
2021-02-12 19:28 ` [PATCH 3/3] vfio/type1: Implement vma registration and restriction Alex Williamson
2021-02-12 22:47 ` kernel test robot
2021-02-12 20:57 ` [PATCH 0/3] vfio: Device memory DMA mapping improvements Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210212212057.GW4247@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterx@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox