> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Tuesday, August 27, 2024 11:52 PM
>
> This control causes the ARM SMMU drivers to choose a stage 2
> implementation for the IO pagetable (vs the stage 1 usual default),
> however this choice has no significant visible impact to the VFIO
> user. Further qemu never implemented this and no other userspace user is
> known.
>
> The original description in commit f5c9ecebaf2a ("vfio/iommu_type1: add
> new VFIO_TYPE1_NESTING_IOMMU IOMMU type") suggested this was to
> "provide
> SMMU translation services to the guest operating system" however the rest
> of the API to set the guest table pointer for the stage 1 and manage
> invalidation was never completed, or at least never upstreamed, rendering
> this part useless dead code.
>
> Upstream has now settled on iommufd as the uAPI for controlling nested
> translation. Choosing the stage 2 implementation should be done by through
> the IOMMU_HWPT_ALLOC_NEST_PARENT flag during domain allocation.
>
> Remove VFIO_TYPE1_NESTING_IOMMU and everything under it including the
> enable_nesting iommu_domain_op.
>
> Just in-case there is some userspace using this continue to treat
> requesting it as a NOP, but do not advertise support any more.
It took me a while to understand why we still allow the user setting the
IOMMU type to nesting below...
> @@ -2545,9 +2538,7 @@ static void *vfio_iommu_type1_open(unsigned
> long arg)
> switch (arg) {
> case VFIO_TYPE1_IOMMU:
> break;
> - case VFIO_TYPE1_NESTING_IOMMU:
> - iommu->nesting = true;
> - fallthrough;
> + case __VFIO_RESERVED_TYPE1_NESTING_IOMMU:
> case VFIO_TYPE1v2_IOMMU:
> iommu->v2 = true;
> break;
I guess the reason was that NESTING_IOMMU implies V2 so an user can
legitimately uses it as V2 w/o counting on any removed nesting logic.
So,
Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
