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.nicol...@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
