nested-smmuv3 topic for QEMU/libvirt, Nov 2024

[Nicolin Chen]

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.nicolinc@nvidia.com/
https://lore.kernel.org/all/cover.1730313494.git.nicolinc@nvidia.com/
https://lore.kernel.org/all/0-v4-9e99b76f3518+3a8-smmuv3_nesting_jgg@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