On Thu, Nov 13, 2025 at 11:37:12AM -0700, Alex Williamson wrote: > > The latest series for interconnect negotation to exchange a phys_addr is: > > > > https://lore.kernel.org/r/[email protected] > > If this is in development, why are we pursuing a vfio specific > temporary "private interconnect" here rather than building on that > work? What are the gaps/barriers/timeline?
I broadly don't expect to see an agreement on the above for probably half a year, and I see no reason to hold this up for it. Many people are asking for this P2P support to be completed in iommufd. Further, I think the above will be easier to work on when we have this merged as an example that can consume it in a different way. Right now it is too theoretical, IMHO. > I don't see any uAPI changes here, is there any visibility to userspace > whether IOMMUFD supports this feature or is it simply a try and fail > approach? So far we haven't done discoverably things beyond try and fail. I'd be happy if the userspace folks doing libvirt or whatever came with some requests/patches for discoverability. It is not just this feature, but things like nesting and IOMMU driver support and so on. > The latter makes it difficult for management tools to select > whether to choose a VM configuration based on IOMMUFD or legacy vfio if > p2p DMA is a requirement. Thanks, In alot of cases it isn't really a choice as you need iommufd to do an accelerated vIOMMU. But yes, it would be nice to eventually automatically use iommufd whenever possible. Thanks, Jason
