RE: nested-smmuv3 topic, Sep 2024

[Shameerali Kolothum Thodi]

Hi Nicolin,

Thanks for the write up and task progress status.

> -----Original Message-----
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Thursday, September 5, 2024 9:26 AM
> To: Eric Auger <eric.auger@redhat.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; Mostafa Saleh
> <smostafa@google.com>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org; Peter Maydell
> <peter.maydell@linaro.org>; Jason Gunthorpe <jgg@nvidia.com>; Jean-
> Philippe Brucker <jean-philippe@linaro.org>; Moritz Fischer
> <mdf@kernel.org>; Michael Shavit <mshavit@google.com>; Andrea
> Bolognani <abologna@redhat.com>; Michael S. Tsirkin <mst@redhat.com>;
> Peter Xu <peterx@redhat.com>
> Subject: nested-smmuv3 topic, Sep 2024
> 
> Hi all,
> 
> Hope I didn't miss anybody who is related to the topic. Please,
> feel free to add!
> 
> <--- Background --->
> As some of you know, there is an ongoing effort for nested-smmuv3
> support in QEMU on ARM, working with the kernel IOMMUFD uAPIs:
> [Nesting for vSTE]
> https://lore.kernel.org/linux-iommu/0-v2-621370057090+91fec-
> smmuv3_nesting_jgg@nvidia.com/
> [Nesting for invalidations]
> https://lore.kernel.org/linux-
> iommu/cover.1724776335.git.nicolinc@nvidia.com/
> 
> The kernel patches are still under review. Jason and I are hoping
> them to get merged at next cycle for v6.13, which means the QEMU
> patches might start a review process as early as Nov/Dec?
> 
> That being said, I think we are way behind the point that patches
> can get reviewed: most of the QEMU patches on my branches weren't
> touched very often, but merely updated to the latest kernel uAPIs
> for verification. So, I feel this might be a good point to gather
> folks together to discuss about the possible timeline and ask for
> help. I think this would potentially help folks who are going to
> attend the KVM forum (or LPC) to carry out a discussion. (Sorry,
> I won't make it due to some conflict..)
> 
> <-- Task Breakdown --->
> I previously sent a RFCv1 series collecting comments/suggestions,
> for multi-vSMMU instance design in ARM Virt code:
> https://lore.kernel.org/qemu-
> devel/cover.1719361174.git.nicolinc@nvidia.com/
> (And thanks again for all the inputs!)
> 
> The main takeaway from the discussion is to
> 1) Turn the vSMMU module into a pluggable one, like intel-iommu
> 2) Move the per-SMMU pxb bus and device auto-assign into libvirt
> 
> Apart from the multi-vSMMU thing, there's basic nesting series:
> 0) Keep updating to the latest kernel uAPIs to support nesting

By this you mean the old HWPT based nested-smmuv3 support?

> 
> I was trying to do all these three, but apparently too ambitious.
> The kernel side of work is still taking a lot of my bandwidth. So
> far I had almost-zero progress on task (1) and completely-zero on
> task (2).
> 
> <-- Help Needed --->
> So, I'm wondering if anyone(s) might have some extra bandwidth in
> the following months helping these two tasks, either of which can
> be a standalone project I think.
> 
> For task (0), I think I can keep updating the uAPI part, although
> it'd need some help for reviews, which I was hoping to occur after
> Intel sends the QEMU nesting backend patches. Once we know how big
> the rework is going to be, we may need to borrow some help at that
> point once again..

I might have some bandwidth starting October and can take a look at 
task 1 above. I haven't gone through the VIOMMU API model completely
yet and plan to do that soon.

Also I am planning to attend KVM forum, so if there are anyone interested
to have  a chat on this, please let me know.

Thanks,
Shameer