Re: [PATCH RFC 00/12] IOMMUFD Generic interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 12, 2022 at 10:13:32PM +0200, Eric Auger wrote:
> Hi,
> 
> On 3/18/22 6:27 PM, Jason Gunthorpe wrote:
> > iommufd is the user API to control the IOMMU subsystem as it relates to
> > managing IO page tables that point at user space memory.
> >
> > It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO
> > container) which is the VFIO specific interface for a similar idea.
> >
> > We see a broad need for extended features, some being highly IOMMU device
> > specific:
> >  - Binding iommu_domain's to PASID/SSID
> >  - Userspace page tables, for ARM, x86 and S390
> >  - Kernel bypass'd invalidation of user page tables
> >  - Re-use of the KVM page table in the IOMMU
> >  - Dirty page tracking in the IOMMU
> >  - Runtime Increase/Decrease of IOPTE size
> >  - PRI support with faults resolved in userspace
> 
> This series does not have any concept of group fds anymore and the API
> is device oriented.
> I have a question wrt pci bus reset capability.
> 
> 8b27ee60bfd6 ("vfio-pci: PCI hot reset interface")
> introduced VFIO_DEVICE_PCI_GET_HOT_RESET_INFO and VFIO_DEVICE_PCI_HOT_RESET
> 
> Maybe we can reuse VFIO_DEVICE_GET_PCI_HOT_RESET_INFO to retrieve the devices and iommu groups that need to be checked and involved in the bus reset. If I understand correctly we now need to make sure the devices are handled in the same security context (bound to the same iommufd)
> 
> however VFIO_DEVICE_PCI_HOT_RESET operate on a collection of group fds.
> 
> How do you see the porting of this functionality onto /dev/iommu?

I already made a patch that converts VFIO_DEVICE_PCI_HOT_RESET to work
on a generic notion of a file and the underlying infrastructure to
allow it to accept either a device or group fd.

Same for the similar issue in KVM.

It is part of three VFIO series I will be posting. First is up here:

https://lore.kernel.org/kvm/0-v1-a8faf768d202+125dd-vfio_mdev_no_group_jgg@xxxxxxxxxx/

Overall the strategy is to contain the vfio_group as an internal detail
of vfio.ko and external interfaces use either a struct vfio_device *
or a struct file *

Jason



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux