Re: [PATCH v20 2/9] firmware: arm_rmm: Check for RMI support at init

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Sep 30, 2026 at 09:18:48AM +0100, Suzuki K Poulose wrote:
> On 29/09/2026 23:28, sashiko-bot@kernel.org wrote:
> > > diff --git a/include/linux/arm-rmi-cmds.h b/include/linux/arm-rmi-cmds.h
> > > new file mode 100644
> > > index 0000000000000..911489b636522
> > > --- /dev/null
> > > +++ b/include/linux/arm-rmi-cmds.h
> > [ ... ]
> > > +static inline void rmi_smccc_invoke(struct arm_smccc_1_2_regs *regs)
> > > +{
> > > +	struct arm_smccc_1_2_regs args = *regs;
> > > +	long status;
> > > +	int i = 0;
> > > +
> > > +	while (i < RMM_BLOCKED_RETRY_COUNT) {
> > > +		arm_smccc_1_2_invoke(&args, regs);
> > > +
> > > +		status = RMI_RESULT_STATUS(regs->a0);
> > > +		if (status != RMI_BUSY && status != RMI_BLOCKED)
> > > +			break;
> > > +		if (status == RMI_BLOCKED)
> > > +			i++;
> > > +		cpu_relax();
> > > +	}
> > 
> > [Severity: High]
> > Does this sequence create an unbounded spin loop if the firmware continuously
> > returns RMI_BUSY?
> > 
> > If the status returned by arm_smccc_1_2_invoke() is RMI_BUSY, the loop
> > continues without incrementing the exit counter i. It issues cpu_relax()
> > but does not yield the CPU (e.g., via cond_resched()) or impose a timeout.
> > If the RMM firmware remains busy, this could cause the host kernel to lock
> > up indefinitely.
> 
> This is like "spinlock contention". RMM returns EBUSY when a resource is
> locked temporarily. We should be able to make progress, unlike the
> RMI_BLOCKED, which is blocking due to a long running operation.

I dug a bit into the RMI_BUSY description in the spec and it's not
always safe to spin forever. For RMI_{PDEV,VDEV}_COMMUNICATE, for
example, we need to return to the caller and retry later (for VDEV, the
spec suggests informing the realm). That's the TSM series, which doesn't
use the new API yet, but something to be aware of when it's updated.

We may need the spec to bound this spin anyway, or at least give an
indication that it's not forever, otherwise it affects latency,
especially in an RT kernel.

There's a generic RMI command return code table in B4.2 that lists
RMI_BUSY for an imp def reason for the command failing to make progress.
Does this apply to something like REC_ENTER? In the KVM series we call
that with IRQs masked.

We might need different APIs here: one for sleepable callers that does
cond_resched() (or backs off) while retrying, and one that returns
-EBUSY, e.g. for TSM, or for commands like REC_ENTER that we don't
expect to see RMI_BUSY and don't want to spin on.

-- 
Catalin