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

[Mostafa Saleh <smostafa@google.com>]

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?

Thanks,
Mostafa

> 
> I don't have a better solution for both pv and emulated root IOMMU
> drivers. Perhaps others do?
>