On Tue, Aug 18, 2026 at 02:01:19PM -0700, Jacob Pan wrote: > The rough flow looks like: > - vmm creates an iommufd ctx > - open cdev FD for the assigned device > - bind vfio cdev FD with iommufd > - vmm calls /dev/mshv or xen to create a partition, stores hv allocated > part_id in its vm FD's file private data > - vmm creates a per vm viommu ojbect of direct attach unique type > - in this hv-iommu-root driver's .viommu_init, fish out the part_id > from the vm file's private data then stores in hv-iommu's viommu > struct. > The rest is for direct domain attach, roughly > - allocate a vdevice under the direct type viommu > - allocate a direct type hwpt (new) > - attach the direct hwpt to the cdev, where this driver can intercept > in its direct domain callback (instead of abusing the paging domain > attach). > > With this flow, the VM identity is explicit through the vIOMMU UAPI > rather than inferred from current tgid.
Yes, this seems broadly OK > One open naming question is whether "direct" is the right term for this > object type since it hints 1:1 mapping which it is not. It really is an > externally managed S2 domain/iopt, so "external" may describe the > semantics better, as Teddy called it in [1]. I also think direct is not a good name. External is not bad with something like 'external hypervisor controlled translation' as perhaps the whole name? Jason
