On Tue, 29 Nov 2022 16:31:45 -0400 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > [ As with the iommufd series, this will be the last posting unless > something major happens, futher fixes will be in new commits ] > > This series provides an alternative container layer for VFIO implemented > using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will > not be compiled in. > > At this point iommufd can be injected by passing in a iommfd FD to > VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer in iommufd > to obtain the compat IOAS and then connect up all the VFIO drivers as > appropriate. > > This is temporary stopping point, a following series will provide a way to > directly open a VFIO device FD and directly connect it to IOMMUFD using > native ioctls that can expose the IOMMUFD features like hwpt, future > vPASID and dynamic attachment. > > This series, in compat mode, has passed all the qemu tests we have > available, including the test suites for the Intel GVT mdev. Aside from > the temporary limitation with P2P memory this is belived to be fully > compatible with VFIO. > > This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd > > It requires the iommufd series: > > https://lore.kernel.org/r/0-v6-a196d26f289e+11787-iommufd_jgg@xxxxxxxxxx > > v4: > - Change the assertion in vfio_group_has_iommu to be clearer > - Use vfio_group_has_iommu() > - Remove allow_unsafe_interrupts stuff > - Update IOMMUFD_VFIO_CONTAINER kconfig description > - Use DEBUG_KERNEL insted of RUNTIME_TESTING_MENU for IOMMUFD_TEST kconfig This looks ok to me and passes all my testing. What's your merge plan? I'm guessing you'd like to send it along with the main IOMMUFD pull request, there are currently no conflicts with my next branch, therefore: Reviewed-by: Alex Williamson <alex.williamson@xxxxxxxxxx> Tested-by: Alex Williamson <alex.williamson@xxxxxxxxxx> Otherwise, let's figure out the branch merge plan. Thanks, Alex
