Re: [PATCH v3 29/29] iommu/arm-smmu-v3-kvm: Add IOMMU ops
From: Mostafa Saleh
Date: Wed Jul 30 2025 - 11:07:30 EST
On Wed, Jul 30, 2025 at 11:42:53AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 28, 2025 at 05:53:16PM +0000, Mostafa Saleh wrote:
> > Register the SMMUv3 through IOMMU ops, that only support identity
> > domains. This allows the driver to know which device are currently used
> > to properly enable/disable then.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@xxxxxxxxxx>
> > ---
> > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-kvm.c | 92 ++++++++++++++++++-
> > 1 file changed, 91 insertions(+), 1 deletion(-)
>
> Can you split the new iommu subysstem driver out please? I think I
> asked this before.
Sorry, maybe I misunderstood, do you mean split this patch into multiple
patches or split all KVM SMMUv3 driver out of this series?
>
> This series is big, reviewing a new iommu driver should be done separately.
>
> Please review all the comments for the verisilicon driver, I think
> many of the remarks apply here too:
Thanks, I will go through them.
>
> - Domain attachment looks questionable. Please do not have
> attach/detach language at all in the hypervisor facing API.
I am not sure I understand this one, the hypervisor API has no
attach/detach APIs?
We only notify the hypervisor via “enable/disable” hypercalls when
devices are attached or released (as only IDENTITY DOMAIN is supported)
so it can enable or disable translation.
> - Get the ordering and APIs right so replace works. You need this to support RMRs
I see, we can’t support bypass for security reasons, but we can enable
the identity map for such devices.
> - Use a blocking domain not some unclear detatch idea
There is not a single detach in this driver, we only support attach and release
operation, which just goes to the hypervisor as enable/disable identity.
> - Use a blocking domain for release
I see, I can add “blocked_domain” similar to “arm_smmu_blocked_domain”
which just disables the device translation, I will look into, I am just
concerned it's more code as this driver only supports a single domain
type.
> - Use the smmu-v3 approach for the fwspec, don't store things in the drvdata.
This is using “dev_iommu_fwspec_get” similar to the SMMUv3 driver,
am I missing something?
The driver only save the "struct arm_smmu_device" in drvdata, which is
exactly what the other driver does (which allows us to re-use a lot of
the code)
Thanks,
Mostafa
>
> Jason