[PATCH v2] iommu/arm-smmu-v3-iommufd: Allow attaching nested domain for GBPA cases

[Will Deacon]

On Mon, Nov 24, 2025 at 03:34:35PM -0400, Jason Gunthorpe wrote:
> On Mon, Nov 03, 2025 at 09:27:55AM -0800, Nicolin Chen wrote:
> > A vDEVICE has been a hard requirement for attaching a nested domain to the
> > device. This makes sense when installing a guest STE, since a vSID must be
> > present and given to the kernel during the vDEVICE allocation.
> > 
> > But, when CR0.SMMUEN is disabled, VM doesn't really need a vSID to program
> > the vSMMU behavior as GBPA will take effect, in which case the vSTE in the
> > nested domain could have carried the bypass or abort configuration in GBPA
> > register. Thus, having such a hard requirement doesn't work well for GBPA.
> > 
> > Skip vmaster allocation in arm_smmu_attach_prepare_vmaster() for an abort
> > or bypass vSTE. Note that device on this attachment won't report vevents.
> > 
> > Update the uAPI doc accordingly.
> > 
> > Tested-by: Shameer Kolothum <skolothumtho at nvidia.com>
> > Signed-off-by: Nicolin Chen <nicolinc at nvidia.com>
> > ---
> > 
> > Changelog
> > v2
> >  * Add Tested-by from Shameer
> >  * Skip vmaster allocation instead of bypassing vsid=0
> >  * Revise the uAPI doc to note a corner case when CR0.SMMUEN=1
> > 
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 13 ++++++++++++-
> >  include/uapi/linux/iommufd.h                        |  9 +++++++++
> >  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
> 
> Will, I will grab this in a few days unless you want it in your tree

Sure, go for it.

Will