Hi, This is a continued discussion following previous month's: https://lore.kernel.org/qemu-devel/Zvr%2Fbf7KgLN1cjOl@Asurada-Nvidia/
Kernel changes are getting closer to merge, as Jason's planning to take vIOMMU series and smmuv3_nesting series into the iommufd tree: https://lore.kernel.org/all/cover.1730313494.git.nicol...@nvidia.com/ https://lore.kernel.org/all/cover.1730313494.git.nicol...@nvidia.com/ https://lore.kernel.org/all/0-v4-9e99b76f3518+3a8-smmuv3_nesting_...@nvidia.com/ So, I think it's probably a good time to align with each others and talk about kicking off some QEMU upstream work in the month ahead. @Shameer, Do you have some update on the pluggable smmuv3 module? Updates on my side: 1) I have kept uAPI updated to the latest version and verified too. There should be some polishing changes depending on how the basic nesting infrastructure would look like from Intel/Duan's work. 2) I got some help from NVIDIA folks for the libvirt task. And they have done some drafting and are now verifying the PCI topology with "iommu=none". Once the pluggable smmuv3 module is ready to test, we will make some change to libvirt for that and drop the auto-assigning patches from the VIRT code, so as to converge for a libvirt+QEMU test. FWIW, Robin requested a different solution for MSI mapping [1], v.s. the RMR one that we have been using since Eric's work. I drafted a few VFIO/IOMMUFD patches for that, yet paused for getting the vIOMMU series merged to this kernel cycle. I plan to continue in Nov/Dec. So, for the near term we will continue with the RMR solution, until we have something solid later. [1] https://lore.kernel.org/linux-iommu/ZrVN05VylFq8lK4q@Asurada-Nvidia/ Thanks Nicolin
