[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIo1ImP7R7VhRpVE@google.com>
Date: Wed, 30 Jul 2025 15:07:14 +0000
From: Mostafa Saleh <smostafa@...gle.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: linux-kernel@...r.kernel.org, kvmarm@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
maz@...nel.org, oliver.upton@...ux.dev, joey.gouly@....com,
suzuki.poulose@....com, yuzenghui@...wei.com,
catalin.marinas@....com, will@...nel.org, robin.murphy@....com,
jean-philippe@...aro.org, qperret@...gle.com, tabba@...gle.com,
mark.rutland@....com, praan@...gle.com
Subject: Re: [PATCH v3 29/29] iommu/arm-smmu-v3-kvm: Add IOMMU ops
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@...gle.com>
> > ---
> > .../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
Powered by blists - more mailing lists