Re: [PATCH 7/8] iommu/amd: Add support for nested domain allocation

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Aug 22, 2025 at 02:45:58PM -0700, Nicolin Chen wrote:
> On Fri, Aug 22, 2025 at 06:16:18PM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 22, 2025 at 12:51:02PM -0700, Nicolin Chen wrote:
> > > > @@ -3113,6 +3116,7 @@ const struct iommu_ops amd_iommu_ops = {
> > > >  	.release_domain = &release_domain,
> > > >  	.identity_domain = &identity_domain.domain,
> > > >  	.domain_alloc_paging_flags = amd_iommu_domain_alloc_paging_flags,
> > > > +	.domain_alloc_nested = amd_iommu_domain_alloc_nested,
> > > >  	.domain_alloc_sva = amd_iommu_domain_alloc_sva,
> > > >  	.probe_device = amd_iommu_probe_device,
> > > >  	.release_device = amd_iommu_release_device,
> > > 
> > > This will be an HWPT-based nesting support, v.s. vIOMMU-based.
> > > 
> > > If AMD wants to enable its Command/Event Buffers, I think this
> > > should follow the vIOMMU model instead.
> > 
> > I've been expecting drivers to do both, like ARM.. Nested is the basic
> > infrastructure and then the viommu changes what domain id nested will
> > use similar to how ARM constrains the VMID based on the viommu.
> 
> Hmm, we haven't implemented both in ARM but only the vIOMMU-based
> one..

Oh? I mis-remember we had kept the hwpt based non-ATS invalidation
around.. I guess that was Intel that ended up like that.. OK then

> Yea, AMD could start with the HWPT-based one, but that would need
> an invalidation op(?), which seems missing in this series. So, to
> support direct invalidation via Command Buffers, vIOMMU should be
> the only option, right?

Certainly if there is no invalidation op the series is incomplete.

Jason