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 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.. Thank you Nicolin
