Hi Nicolin, Thanks for the write up and task progress status.
> -----Original Message----- > From: Nicolin Chen <[email protected]> > Sent: Thursday, September 5, 2024 9:26 AM > To: Eric Auger <[email protected]>; Shameerali Kolothum Thodi > <[email protected]>; Mostafa Saleh > <[email protected]> > Cc: [email protected]; [email protected]; Peter Maydell > <[email protected]>; Jason Gunthorpe <[email protected]>; Jean- > Philippe Brucker <[email protected]>; Moritz Fischer > <[email protected]>; Michael Shavit <[email protected]>; Andrea > Bolognani <[email protected]>; Michael S. Tsirkin <[email protected]>; > Peter Xu <[email protected]> > 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- > [email protected]/ > [Nesting for invalidations] > https://lore.kernel.org/linux- > iommu/[email protected]/ > > 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/[email protected]/ > (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
