All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, ajones@ventanamicro.com,
	yan.y.zhao@intel.com, kevin.tian@intel.com, peterx@redhat.com
Subject: Re: [PATCH 2/2] vfio/pci: Use unmap_mapping_range()
Date: Fri, 24 May 2024 10:42:56 -0300	[thread overview]
Message-ID: <20240524134256.GX20229@nvidia.com> (raw)
In-Reply-To: <20240523195629.218043-3-alex.williamson@redhat.com>

On Thu, May 23, 2024 at 01:56:27PM -0600, Alex Williamson wrote:
> With the vfio device fd tied to the address space of the pseudo fs
> inode, we can use the mm to track all vmas that might be mmap'ing
> device BARs, which removes our vma_list and all the complicated lock
> ordering necessary to manually zap each related vma.
> 
> Note that we can no longer store the pfn in vm_pgoff if we want to use
> unmap_mapping_range() to zap a selective portion of the device fd
> corresponding to BAR mappings.
> 
> This also converts our mmap fault handler to use vmf_insert_pfn()
> because we no longer have a vma_list to avoid the concurrency problem
> with io_remap_pfn_range().  The goal is to eventually use the vm_ops
> huge_fault handler to avoid the additional faulting overhead, but
> vmf_insert_pfn_{pmd,pud}() need to learn about pfnmaps first.
> 
> Also, Jason notes that a race exists between unmap_mapping_range() and
> the fops mmap callback if we were to call io_remap_pfn_range() to
> populate the vma on mmap.  Specifically, mmap_region() does call_mmap()
> before it does vma_link_file() which gives a window where the vma is
> populated but invisible to unmap_mapping_range().
> 
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/vfio/pci/vfio_pci_core.c | 256 +++++++------------------------
>  include/linux/vfio_pci_core.h    |   2 -
>  2 files changed, 56 insertions(+), 202 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

  parent reply	other threads:[~2024-05-24 13:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 19:56 [PATCH 0/2] vfio/pci: vfio device address space mapping Alex Williamson
2024-05-23 19:56 ` [PATCH 1/2] vfio: Create vfio_fs_type with inode per device Alex Williamson
2024-05-24 13:24   ` Jason Gunthorpe
2024-05-29 23:59   ` Tian, Kevin
2024-05-23 19:56 ` [PATCH 2/2] vfio/pci: Use unmap_mapping_range() Alex Williamson
2024-05-24  0:39   ` Yan Zhao
2024-05-24  0:49     ` Peter Xu
2024-05-24  1:47       ` Yan Zhao
2024-05-28 18:42         ` Alex Williamson
2024-05-29  2:29           ` Yan Zhao
2024-05-29  3:12             ` Alex Williamson
2024-05-29  6:34               ` Yan Zhao
2024-05-29 16:50                 ` Alex Williamson
2024-05-30  7:46                   ` Yan Zhao
2024-05-24  8:40       ` Tian, Kevin
2024-05-24 13:22         ` Jason Gunthorpe
2024-05-24 23:15           ` Peter Xu
2024-05-24 13:42   ` Jason Gunthorpe [this message]
2024-05-30  0:09   ` Tian, Kevin
2024-05-30  2:22     ` Alex Williamson
2024-05-30  2:47       ` Tian, Kevin

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=20240524134256.GX20229@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ajones@ventanamicro.com \
    --cc=alex.williamson@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=peterx@redhat.com \
    --cc=yan.y.zhao@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.