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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Nov 09, 2026 at 10:42:00PM -0800, Jacob Pan wrote:
> Hi Jason,
> 
> On Mon, 9 Nov 2026 20:52:59 -0400
> Jason Gunthorpe <jgg@ziepe.ca> wrote:
> 
> > On Fri, Nov 06, 2026 at 01:03:52PM -0800, Jacob Pan wrote:
> > > 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.  
> > 
> > You've basically described a wonky NESTING domain.
> > 
> > I think you should just use nested domains for this. Even though there
> > is no S2 make it possible to create a nested domain through the
> > viommu..
> I didn't use nested domain since the current parent hwpt is a paging
> domain which cannot be used to express the external attach semantics.
> 
> Are you saying that we create a parent-less VIOMMU (in Aneesh's patchset
> and my RFC), and modify the iommufd core code to allow nested domains
> to be formed with an externally managed parent? or we expose a
> opague parent S2 that is not paging domain?

Just use a null S2 for this. If the viommu was created without a S2
then the nesting domains should be created that way too.

Once you do that you have a normal HWPT representing the S1
translation in the guest (identity to start) and everything works the
normal way.

The only wrinkle in your setup is you don't have a S2 at all. Not even
a placeholder.

> But if we go with the nested domain route and let hyperv iommu driver
> handle the nested domain attach, it still would not work for pKVM.
> pKVM's root SMMU is emulated, so it cannot do the external attach
> hypercall in the unmodified SMMU driver.

Yeah, I think it is fine that the hypercall is not part of the smmu
driver..

> So I am willing to entertain Mostafa's approach to park the device in
> blocking domain, then use hypervisor provided viommu/vdevice ops to
> invoke device external attach hypercall. Basically, move the
> attach_device to external S2 operation out of iommu driver to the
> hypervisor code. It does not need domain ID or anything IOMMU specific.

Right, though in your case some co-ordination is probably helpful
since things might go strange if the hypervisor side and iommu driver
side disagree on what the translation is

Jason