| Message ID | 161401167013.16443.8389863523766611711.stgit@gimli.home (mailing list archive) |
|---|---|
| Headers | show |
| Series | vfio: Device memory DMA mapping improvements | expand |
On Mon, Feb 22, 2021 at 09:50:22AM -0700, Alex Williamson wrote: > This is a re-implementation of [1] following suggestions and code from > Jason Gunthorpe. This is lightly tested but seems functional and > throws no lockdep warnings. In this series we tremendously simplify > zapping of vmas mapping device memory using unmap_mapping_range(), we > create a protocol for looking up a vfio_device from a vma and provide > an interface to get a reference from that vma, using that device > reference, the caller can register a notifier for the device to > trigger on events such as device release. This notifier is only > enabled here for vfio-pci, but both the vma policy and the notifier > trigger should be trivial to add to any vfio bus driver after RFC. > > Does this look more like the direction we should go? Yep, it seems pretty good already, see my remarks in each patch For security only vfio_device's that have been enabled for P2P, set the vm_pgoff to the pfn, and trigger invalidation, should be used with this mechanism. I'd add some global opt-in so vfio_device_get_from_vma() will refuse to return vfio_device's that don't declare they have support. Add a flags member to vfio_device_ops would get it done fairly cleanly Jason
This is a re-implementation of [1] following suggestions and code from Jason Gunthorpe. This is lightly tested but seems functional and throws no lockdep warnings. In this series we tremendously simplify zapping of vmas mapping device memory using unmap_mapping_range(), we create a protocol for looking up a vfio_device from a vma and provide an interface to get a reference from that vma, using that device reference, the caller can register a notifier for the device to trigger on events such as device release. This notifier is only enabled here for vfio-pci, but both the vma policy and the notifier trigger should be trivial to add to any vfio bus driver after RFC. Does this look more like the direction we should go? Note that like the last series we're still not dropping DMA mappings on device memory disable as this would likely break userspace in some instances, we don't have IOMMU interfaces to modify protection bits, and it's not clear an IOMMU fault is absolutely better than the bus error. Thanks, Alex [1]https://lore.kernel.org/kvm/161315658638.7320.9686203003395567745.stgit@gimli.home/T/#m64859ccd7d92f39a924759c7423f2dcf7d367c84 --- Alex Williamson (10): vfio: Create vfio_fs_type with inode per device vfio: Update vfio_add_group_dev() API vfio: Export unmap_mapping_range() wrapper vfio/pci: Use vfio_device_unmap_mapping_range() vfio: Create a vfio_device from vma lookup vfio: Add a device notifier interface vfio/pci: Notify on device release vfio/type1: Refactor pfn_list clearing vfio/type1: Pass iommu and dma objects through to vaddr_get_pfn vfio/type1: Register device notifier drivers/vfio/Kconfig | 1 drivers/vfio/fsl-mc/vfio_fsl_mc.c | 6 - drivers/vfio/mdev/vfio_mdev.c | 5 - drivers/vfio/pci/vfio_pci.c | 223 ++++---------------------- drivers/vfio/pci/vfio_pci_private.h | 3 drivers/vfio/platform/vfio_platform_common.c | 7 + drivers/vfio/vfio.c | 143 +++++++++++++++-- drivers/vfio/vfio_iommu_type1.c | 211 ++++++++++++++++++++----- include/linux/vfio.h | 19 ++ 9 files changed, 368 insertions(+), 250 deletions(-)