On Mon, May 18, 2026 at 10:41:36PM -0700, Jacob Pan wrote: > Just wondering what work is needed to support this "direct attach"? I > felt this issue is due to trying to cram two distinct domain types > (paging domain & direct attach) into the VFIO container model where > only unmanaged paging domain is supported.
Xen has the same issue and you two need to come up with a uniform solution. VFIO container can't support it, that's out. You should be focusing on a iommufd flow that accepts some FD representing the VM (ie KVM FD) that can be converted by the driver into a HWPT representing that FD's S2 translation. > I am thinking if we were to switch to iommufd and let user(vmm) have > direct control of HWPT, vmm will be able to selectively use a > different domain type to handle direct attach. Yes > IMHO, it is essentially the same as attaching nest parent domain > without nested domain immediately attached. The unprivileged guest > may attach nested domain directly with Hyper-V if nested translation > is needed. nest parent domain is really for supporting the viommu objects.. If you don't have that flow you don't need to worry about that nest parent stuff. > From this driver POV, it will allocate a 2nd stage only domain with > different domain ops (w/o map/unmap) for "direct attach" thus avoid this > hack. Yes, from a driver POV you need a unique iommu_domain allocator that returns an iommu_domain without an ops. It should probably work similarly to the viommu where the iommufd path can send in a driver-specific tagged struct that can describe these special domains. But be mindful of the lifetime rules, whatever ID is used to describe the VM at the hypercall boundary has to be bound into a linux FD and become immutable. The driver has to hold that FD as long as the domain exists. Jason
