mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [GIT PULL] VFIO fixes for v6.10-rc4
Date: Fri, 14 Jun 2024 15:56:03 -0600	[thread overview]
Message-ID: <20240614155603.34567eb7.alex.williamson@redhat.com> (raw)

Hi Linus,

The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0:

  Linux 6.10-rc1 (2024-05-26 15:20:12 -0700)

are available in the Git repository at:

  https://github.com/awilliam/linux-vfio.git tags/vfio-v6.10-rc4

for you to fetch changes up to d71a989cf5d961989c273093cdff2550acdde314:

  vfio/pci: Insert full vma on mmap'd MMIO fault (2024-06-12 15:40:39 -0600)

----------------------------------------------------------------
VFIO fixes for v6.10-rc4

 - Fix long standing lockdep issue of using remap_pfn_range() from
   the vfio-pci fault handler for mapping device MMIO.  Commit
   ba168b52bf8e ("mm: use rwsem assertion macros for mmap_lock") now
   exposes this as a warning forcing this to be addressed.

   remap_pfn_range() was used here to efficiently map the entire vma,
   but it really never should have been used in the fault handler and
   doesn't handle concurrency, which introduced complex locking.  We
   also needed to track vmas mapping the device memory in order to zap
   those vmas when the memory is disabled resulting in a vma list.

   Instead of all that mess, setup an address space on the device fd
   such that we can use unmap_mapping_range() for zapping to avoid
   the tracking overhead and use the standard vmf_insert_pfn() to
   insert mappings on fault.  For now we'll iterate the vma and
   opportunistically try to insert mappings for the entire vma.  This
   aligns with typical use cases, but hopefully in the future we can
   drop the iterative approach and make use of huge_fault instead,
   once vmf_insert_pfn{pud,pmd}() learn to handle pfnmaps.
   (Alex Williamson)

----------------------------------------------------------------
Alex Williamson (3):
      vfio: Create vfio_fs_type with inode per device
      vfio/pci: Use unmap_mapping_range()
      vfio/pci: Insert full vma on mmap'd MMIO fault

 drivers/vfio/device_cdev.c       |   7 +
 drivers/vfio/group.c             |   7 +
 drivers/vfio/pci/vfio_pci_core.c | 271 ++++++++++-----------------------------
 drivers/vfio/vfio_main.c         |  44 +++++++
 include/linux/vfio.h             |   1 +
 include/linux/vfio_pci_core.h    |   2 -
 6 files changed, 125 insertions(+), 207 deletions(-)


             reply	other threads:[~2024-06-14 21:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14 21:56 Alex Williamson [this message]
2024-06-15  3:01 ` pr-tracker-bot

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=20240614155603.34567eb7.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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

all inboxes | Powered by JetHome®