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/20251027044712.1676175-1-vivek.kasireddy@intel.com
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