Hi Jason,
On Wed, 5 Aug 2026 09:48:38 -0300
Jason Gunthorpe <[email protected]> wrote:
> > +/*
> > + * If the current thread is a VMM thread, return the partition id
> > of the VM it
> > + * is managing, else return HV_PARTITION_ID_INVALID.
> > + */
> > +static u64 hv_get_current_partid(void)
> > +{
>
> No, you cannot transparently detect VMMs and link them like this. The
> VMM makes it self visible to the iommu driver via the viommu interface
> and you get a kvm FD to fish your partid out of. This is hackery not
> OK.
>
> You should come with VMM support as a followup once you get a basic
> kernel-only iommu driver working.
Agreed with the plan, we should drop the current-thread based VMM
detection from this series and keep this driver focused on the
kernel-only IOMMU path, use part_id self for the time being.
I have been working on a prototype that is based on viommu/vdevice/hwpt
for "direct attach" model, aka "hypercalls to move the device into the
selected guest" in the discussions of the previous version of this
patch.
It is based on our previous discussions with Xen as well.
[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/linux-iommu/[email protected]/
The viommu object for direct attach should also cover the part_id
retrieval from the partition created by mshv or xen.
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.
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 plan to send out RFC in the next few weeks before LPC. Any
feedback highly appreciated.
+Teddy
Thanks,
Jacob
