RE: [PATCH v1 8/8] iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Nicolin Chen <nicolinc@xxxxxxxxxx>
> Sent: 28 October 2026 18:09
> To: Shameer Kolothum Thodi <skolothumtho@xxxxxxxxxx>
> Cc: Jason Gunthorpe <jgg@xxxxxxxxxx>; Catalin Marinas
> <catalin.marinas@xxxxxxx>; Will Deacon <will@xxxxxxxxxx>;
> joro@xxxxxxxxxx; Robin Murphy <robin.murphy@xxxxxxx>;
> rafael@xxxxxxxxxx; Danilo Krummrich <dakr@xxxxxxxxxx>; Marek Szyprowski
> <m.szyprowski@xxxxxxxxxxx>; aneesh.kumar@xxxxxxxxxx; Mark Rutland
> <mark.rutland@xxxxxxx>; Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx>; Suzuki K Poulose
> <suzuki.poulose@xxxxxxx>; Gavin Shan <gshan@xxxxxxxxxx>; Vikram Sethi
> <vsethi@xxxxxxxxxx>; Anshuman Khandual
> <anshuman.khandual@xxxxxxx>; Shanker Donthineni
> <sdonthineni@xxxxxxxxxx>; Mostafa Saleh <smostafa@xxxxxxxxxx>;
> rppt@xxxxxxxxxx; Thomas Huth <thuth@xxxxxxxxxx>; Marc Zyngier
> <maz@xxxxxxxxxx>; Ryan Roberts <ryan.roberts@xxxxxxx>; kas@xxxxxxxxxx;
> Kohei Enju <enju.kohei@xxxxxxxxxxx>; Shaopeng Tan
> <tan.shaopeng@xxxxxxxxxxxxxx>; Ard Biesheuvel <ardb@xxxxxxxxxx>; James
> Morse <james.morse@xxxxxxx>; Steven Price <steven.price@xxxxxxx>;
> Sang-Heon Jeon <ekffu200098@xxxxxxxxx>; Omar Sandoval
> <osandov@xxxxxx>; Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; Jinjie
> Ruan <ruanjinjie@xxxxxxxxxx>; Sam Edwards <cfsworks@xxxxxxxxx>;
> Douglas Anderson <dianders@xxxxxxxxxxxx>; Florian Fainelli
> <florian.fainelli@xxxxxxxxxxxx>; Chen-Yu Tsai <wenst@xxxxxxxxxxxx>;
> Huacai Chen <chenhuacai@xxxxxxxxxx>; Thomas Zimmermann
> <tzimmermann@xxxxxxx>; Pranjal Shrivastava <praan@xxxxxxxxxx>; Ashish
> Mhetre <amhetre@xxxxxxxxxx>; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxx; driver-core@xxxxxxxxxxxxxxx;
> Sonang Patel <sonangp@xxxxxxxxxx>; Ankit Agrawal <ankita@xxxxxxxxxx>
> Subject: Re: [PATCH v1 8/8] iommu/arm-smmu-v3: Probe a guest-level Realm
> VSMMU via RSI commands
> 
> On Wed, Oct 28, 2026 at 08:41:13AM -0700, Shameer Kolothum Thodi
> wrote:
> > > @@ -5542,6 +5591,12 @@ static int arm_smmu_device_probe(struct
> > > platform_device *pdev)
> > >  	}
> > >  	ioaddr = res->start;
> > >
> > > +	if (is_realm_world()) {
> > > +		ret = arm_smmu_probe_realm_vsmmu(smmu, res);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> >
> > If probe fails after activation succeeds above, wouldn't a module
> > reload hit RSI_ERROR_DEVICE since the VSMMU is still ACTIVE?
> >
> > B5.4.1.2:
> >
> >  pre:  vsmmu.state == VSMMU_ACTIVE
> >  post: result == RSI_ERROR_DEVICE
> >
> > How is recovery handled?
> 
> There is no way to undo an activation. But what's the practical
> use case for the SMMU driver to do a module reload?

I was thinking of an allocation failure, then onlining more memory
and retrying probe. Not sure how realistic that is in practice.

Any idea why guest side deactivation isn't allowed? I couldn't find
the rationale in the spec. Perhaps it needs additional synchronization.

Thanks,
Shameer