RE: [PATCH v1 2/8] firmware: arm_rmm: Add VSMMU commands and fields

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Nicolin Chen <nicolinc@xxxxxxxxxx>
> Sent: 28 October 2026 18:38
> To: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Cc: Shameer Kolothum Thodi <skolothumtho@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 2/8] firmware: arm_rmm: Add VSMMU commands and
> fields
> 
> On Wed, Oct 28, 2026 at 09:35:09AM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 28, 2026 at 09:49:53AM +0000, Shameer Kolothum Thodi
> wrote:
> > > > +static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
> > > > +						  unsigned long dev_type)
> > > > +{
> > > > +	struct arm_smccc_res res;
> > > > +
> > > > +	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,
> > > > dev_type, &res);
> > >
> > > These calls leave unused input registers unspecified, whereas
> > > DEN0137 bet3 B1.2 marks them SBZ. Could we explicitly zero them?
> > >
> > > "On calling an RMI or RSI command, any of X1- X16 which are not
> > >  specified as input values in the command definition SBZ"
> >
> > That seems too broad, Linux doesn't even support the x8-x16 inputs in
> > the macros. I think the spec has errd here.
> >
> > Requiring zeroing of x0-x7 is sort of reasonable. Any future use of
> > x8-x16 (including outputs) should require a direct opt in of the OS to
> > indicate it supports this bank of registers.
> >
> > Otherwise you probably need a new macro helper for this protocol..
> 
> We could probably replace it with:
> 	arm_smccc_smc(SMC_RSI_ARCH_DEV_ACTIVATE, base, dev_type, 0,
> 0, 0, 0, 0,
> 		      &res);
> 
> This should specify those unused inputs.

Or we could use arm_smccc_1_2_smc() with zero initialized registers, as
rsi_attestation_token_init() does. I think that would cover X8-X16 too.

But other RSI wrappers don't do that consistently, so it's fine either
way, I guess.

Thanks,
Shameer