Re: [PATCH v6 05/25] iommu/arm-smmu-v3: Move IDR parsing to common functions

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, May 07, 2026 at 10:13:13AM +0000, Mostafa Saleh wrote:
> > I was thinking more like
> > 
> > #define arm_smmu arm_pkvm_smmu
> > 
> > Before the pkvm compile of the shared code. 
> 
> Oh, so we rely on arm_pkvm_smmu and arm_smmu having the same field
> names and types?

Just for the shared code, yes.

For instance this patch would require the features field be present in
both, and then all you do is directly copy all the smmu->features
logic into the shared file and that's it.

> I don’t think that’s better for maintainability, I can look into it
> if Robin and Will are OK with that.

I think maintainability here means pkvm minimizes how much it changes
the code of the main driver.

Copying a bunch of functions into a shared .c file exactly as it is,
then compiling the shared file with some #ifdef'ery at is going to be
long term better than trying to mangle the whole thing to avoid using
any of the core types and not directly share the code, IMHO.

Like my tlbi point for instance, it is not a good idea to rip out a
little bit of the invalidation logic then open code a pkvm
version. Use the exact driver code. But to do this you need to pass an
arm_smmu through to to the pkvm specific queue management functions.

> > How does pkvm compilation work anyhow? Is it all rolled into a unique
> > link, or do you have to worry about symbol conflicts with the main
> > kernel?
> 
> All pkvm symbols are prefixed with __kvm_nvhe_ in the main kernel.

So automatically with objcopy or something like that during the build?

Jason