Re: [PATCH RFC 1/9] iommu: Introduce external attach domain type

[Jacob Pan]

Hi Jason,

On Wed, 4 Nov 2026 13:08:16 -0400
Jason Gunthorpe <jgg@xxxxxxxx> wrote:

> On Wed, Nov 04, 2026 at 10:27:43AM +0000, Mostafa Saleh wrote:
> > On Mon, Oct 26, 2026 at 04:10:03PM -0700, Jacob Pan wrote:  
> > > Hi Mostafa,
> > > 
> > > On Wed, 21 Oct 2026 10:57:20 +0000
> > > Mostafa Saleh <smostafa@xxxxxxxxxx> wrote:
> > >   
> > > > On Fri, Sep 25, 2026 at 12:07:34PM -0700, Jacob Pan wrote:  
> > > > > Add IOMMU_DOMAIN_EXTERNAL for externally managed domains that
> > > > > move or attach devices to another VM address space
> > > > > provisioned by an external owner, such as a type 1 hypervisor.
> > > > > 
> > > > > This is not a paging domain and is not sysfs-selectable as a
> > > > > default domain type. It requires external owner context, such
> > > > > as a vIOMMU. 
> > > > 
> > > > Can't we use a IOMMU_DOMAIN_BLOCKED domain for that, AFAIU, the
> > > > host never inserts any mapping?  
> > > Right, the host does not own or install any mappings.
> > > 
> > > The external domain type is nevertheless useful for two reasons:
> > > 
> > > 1. It allows the pvIOMMU driver's domain ops to do the MSHV & Xen
> > > attach and detach hypercalls 
> > > 2. It allows an externally managed device to leverage the normal
> > > IOMMUFD device-to-HWPT attachment interface:
> > > VFIO_DEVICE_ATTACH_IOMMUFD_PT No new ioctls.
> > > 
> > > It also makes the lifetime and ownership clear for IOMMUFD and
> > > hypervisor, the device can be returned back to host iommufd owned
> > > domains once detached.
> > > 
> > > In pKVM case, my understanding is that you have a emulated root
> > > SMMU which does not do hypercalls obviously. Then the external
> > > attach is done via an "out of tree uAPI through KVM/VFIO bridge
> > > IOCTLs that proxies those hypercalls."
> > > 
> > > Therefore, if we were to park the device in blocking domain while
> > > doing external attach (as you suggested), this requires a new PV
> > > only uAPI that must support pkvm, MSHV, and Xen. So it does not
> > > fit in the flow supported by PV IOMMU root driver.  
> > 
> > I am not sure I understand this, how can the domain type change the
> > uAPI? can you please point to what breaks in the code if a blocking
> > domain was used?  
> 
> Yeah me too.. The plan for the CC side with TDX/RMM is to not have a
> S2 domain in the viommu side at all. It should not be uapi brealing in
> the sense that nothing using mshv viommu exists today.
> 
I am not stating that it will break UAPI because of blocking domain is
used. What I am trying to say is that with the blocking domain ->
external transition, we do not need a new UAPI for external attach for
non-CC. It will just reuse the existing UAPI.
VMM:
	do_ioctl(vfio_cdev_fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, &attach,
			"VFIO_DEVICE_ATTACH_IOMMUFD_PT");
hv-iommu-root: external_domain.attach_dev() will do the hypercall.

With blocking domain, this external attachment operation must be under
another UAPI (could well be based vIOMMU/vDevice).

I think it can accommodate both pKVM & MSHV. i.e. move the attach_dev op
out of iommu driver to mshv/pkvm code. I think this goes well with CC
where there is no S2 domain.

For MSHV, the external attach hyper call does not need domain info.
MSHV should have all these info if it is also the viommu/vdevice
provider. This aligns well with Aneesh's patch.

		input->partition_id = partid;
		input->device_id = host_devid;
		input->attdev_flags.logical_id = 1;
		input->logical_devid = vdev_id;
		status = hv_do_hypercall(HVCALL_ATTACH_DEVICE, input, NULL);

> In mshv case the iommu drivers are telling the hypervisor what to do,
> so they have to effectively see a change in translation. But maybe
> this can be managed internally to the driver by annotating the
> blocking domain attachment?
I am not following what the annotation is for? yes, hv-iommu-root
driver can put device in blocking domain, if VMM is to orchestrate the
external assignment, it already knows a device is in blocking domain.

If we let mshv/pkvm to perform direct attach, there must be a in-kernel
agreedment that the device is already in blocking domain. Is this the
annotation for?

This new UAPI also needs to support roll back to normal blocking
and paging domain after external detach.

Thanks,

Jacob