[Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
Tian, Kevin
kevin.tian at intel.com
Tue Apr 18 01:28:12 UTC 2023
> From: Jason Gunthorpe
> Sent: Monday, April 17, 2023 9:39 PM
>
> On Fri, Apr 14, 2023 at 09:11:30AM +0000, Tian, Kevin wrote:
>
> > The only corner case with this option is when a user mixes group
> > and cdev usages. iirc you mentioned it's a valid usage to be supported.
> > In that case the kernel doesn't have sufficient knowledge to judge
> > 'resettable' as it doesn't know which groups are opened by this user.
>
> IMHO we don't need to support this combination.
>
> We can say that to use the hot reset API the user must put all their
> devices into the same iommufd_ctx and cover 100% of the known use
> cases for this.
Make sense.
>
> There are already other situations, like nesting, that do force users
> to put everything into one iommufd_ctx.
>
> No reason to make things harder and more complicated.
>
> I'm coming to the feeling that we should put no-iommu devices in
> iommufd_ctx's as well. They would be an iommufd_access like
> mdevs. That would clean up the complications they cause here.
This certainly simplifies the matter a lot!
>
> I suppose we should have done that from the beginning - no-iommu is an
> IOMMUFD access, it just uses a crazy /proc based way to learn the
> PFNs. Making it a proper access and making a real VFIO ioctl that
> calls iommufd_access_pin_pages() and returns the DMA mapped addresses
> to userspace would go a long way to making no-iommu work in a logical,
> usable, way.
>
Yes. This would provide a more reliable/clean way to learn PFNs for
noiommufd case.
More information about the Intel-gfx
mailing list