RE: [PATCH v2 1/8] vfio: Remove VFIO_TYPE1_NESTING_IOMMU
From: "Tian, Kevin" <kevin.tian@intel.com>
Date: 2024-08-30 07:41:53
Also in:
kvm, linux-acpi, linux-iommu, linux-patches
From: Jason Gunthorpe <jgg@nvidia.com>
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...
quoted hunk ↗ jump to hunk
@@ -2545,9 +2538,7 @@ static void *vfio_iommu_type1_open(unsignedlong 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@intel.com>