Hi Nicolin, Thanks for the write up and task progress status.
> -----Original Message----- > From: Nicolin Chen <nicol...@nvidia.com> > Sent: Thursday, September 5, 2024 9:26 AM > To: Eric Auger <eric.au...@redhat.com>; Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; Mostafa Saleh > <smost...@google.com> > Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; Peter Maydell > <peter.mayd...@linaro.org>; Jason Gunthorpe <j...@nvidia.com>; Jean- > Philippe Brucker <jean-phili...@linaro.org>; Moritz Fischer > <m...@kernel.org>; Michael Shavit <msha...@google.com>; Andrea > Bolognani <abolo...@redhat.com>; Michael S. Tsirkin <m...@redhat.com>; > Peter Xu <pet...@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_...@nvidia.com/ > [Nesting for invalidations] > https://lore.kernel.org/linux- > iommu/cover.1724776335.git.nicol...@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.nicol...@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
