Re: [PATCH v5 7/9] x86/hyperv: Implement Hyper-V virtual IOMMU

[Jason Gunthorpe <jgg@nvidia.com>]

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