Re: nested-smmuv3 topic for QEMU/libvirt, Nov 2024

[Nicolin Chen <nicolinc@nvidia.com>]

On Mon, Nov 18, 2024 at 06:59:53PM +0100, Eric Auger wrote:
> Looking at your branch I see the following series (marked with cover-letter)
..
>     cover-letter: Add RMR WAR for MSI mappings (based on former RMR flat
>     mapping and not related to *[PATCH RFCv1 0/7] vfio: Allow userspace
>     to specify the address for each MSI vector
>     <https://lore.kernel.org/kvm/cover.1731130093.git.nicolinc@nvidia.com/#r>
>     I guess)*

Yes, I think we would postpone this series, by simply putting it
on top of our future shared branches while waiting for the kernel
solution gets finalized to a certain degree, to make sure an MSI
2-stage mapping could still work.

>     cover-letter: hw/arm/virt: Add multiple nested SMMUs (Nicolin ->
>     Shameer)

Yes

>     cover-letter: Add HW accelerated nesting support for arm SMMUv3
>     (Nicolin)

I think this will be moved to Don (or Don/Nic)?

>     cover-letter: Add VIOMMU infrastructure support (Nicolin)

Yes.


>     cover-letter: intel_iommu: Enable stage-1 translation for
>     passthrough device (Zhenzhong)
..
>     cover-letter: intel_iommu: Enable stage-1 translation for emulated
>     device (Zhenzhong)

Yes. We'll need the HWPT infrastructure patches in Intel's series
and I think Intel's progress is faster so Zhenzhong should be the
submitter.

> *Are there any posts upstream for the rest, besides Shameer's respin?

Not yet. I think the dependency should be
(1) HWPT infrastructure (Zhenzhong's Intel series)
(2) VIOMMU infrastructure
(3) smmuv3-acc series (2-stage translation)
(4) Multi vSMMU instance support (VIRT and IORT)
(5) RMR

> *
> >
> > I expect the IOMMU_HWPT_ALLOC (backend APIs) will go with Intel's
> > series once their current "emulated devices" one gets merged. And
> > I think I can prepare IOMMU_VIOMMU_ALLOC patches for backend APIs
> > aligning with HWPT's.
> Can you point us to the actual series including this IOMMU_HWPT_ALLOC
> support? This would clarify which part you are going to work on next.

https://github.com/yiliu1765/qemu/commits/zhenzhong/iommufd_nesting_rfcv2/
Though not planning to do so since it's unlikely the case, yet HWPT
changes could go with the vSMMU series if we're running faster than
Zhenzhong :)

> >
> > That being said, one thing I am not sure is how we should bridge
> > between these backend APIs and a virtual IOMMUs (vSMMU/intel). I
> > think it'd be better for you and Red Hat to provide some insight,
> > if calling the backend APIs directly from a viommu module isn't a
> > preferable way.
> can you clarify what you call backend API in that context?
> >
> > We also need your comments on vSMMU module patches that are still
> > roughly a draft requiring a rework at some small details I think.
> > So, if your (and Don's) bandwidth allows, perhaps you could take
> > over the vSMMU patches? Otherwise, we can also share the task for
> > reworking.
> So we have started the multi smmu instantiation review and provided
> feedbacks.
> Which part can we work on then?

This one:
     cover-letter: Add HW accelerated nesting support for arm SMMUv3
i.e. (3) that I put the list above.

Thanks
Nicolin