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

[Jason Gunthorpe <jgg@ziepe.ca>]

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@google.com> 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.

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?

Jason