[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 at nvidia.com>
> Sent: 28 October 2026 18:09
> To: Shameer Kolothum Thodi <skolothumtho at nvidia.com>
> Cc: Jason Gunthorpe <jgg at nvidia.com>; Catalin Marinas
> <catalin.marinas at arm.com>; Will Deacon <will at kernel.org>;
> joro at 8bytes.org; Robin Murphy <robin.murphy at arm.com>;
> rafael at kernel.org; Danilo Krummrich <dakr at kernel.org>; Marek Szyprowski
> <m.szyprowski at samsung.com>; aneesh.kumar at kernel.org; Mark Rutland
> <mark.rutland at arm.com>; Greg Kroah-Hartman
> <gregkh at linuxfoundation.org>; Suzuki K Poulose
> <suzuki.poulose at arm.com>; Gavin Shan <gshan at redhat.com>; Vikram Sethi
> <vsethi at nvidia.com>; Anshuman Khandual
> <anshuman.khandual at arm.com>; Shanker Donthineni
> <sdonthineni at nvidia.com>; Mostafa Saleh <smostafa at google.com>;
> rppt at kernel.org; Thomas Huth <thuth at redhat.com>; Marc Zyngier
> <maz at kernel.org>; Ryan Roberts <ryan.roberts at arm.com>; kas at kernel.org;
> Kohei Enju <enju.kohei at fujitsu.com>; Shaopeng Tan
> <tan.shaopeng at jp.fujitsu.com>; Ard Biesheuvel <ardb at kernel.org>; James
> Morse <james.morse at arm.com>; Steven Price <steven.price at arm.com>;
> Sang-Heon Jeon <ekffu200098 at gmail.com>; Omar Sandoval
> <osandov at fb.com>; Andrew Morton <akpm at linux-foundation.org>; Jinjie
> Ruan <ruanjinjie at huawei.com>; Sam Edwards <cfsworks at gmail.com>;
> Douglas Anderson <dianders at chromium.org>; Florian Fainelli
> <florian.fainelli at broadcom.com>; Chen-Yu Tsai <wenst at chromium.org>;
> Huacai Chen <chenhuacai at kernel.org>; Thomas Zimmermann
> <tzimmermann at suse.de>; Pranjal Shrivastava <praan at google.com>; Ashish
> Mhetre <amhetre at nvidia.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; iommu at lists.linux.dev; driver-core at lists.linux.dev;
> Sonang Patel <sonangp at nvidia.com>; Ankit Agrawal <ankita at nvidia.com>
> 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