Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI

[Marc Zyngier]

On Tue, 03 Mar 2026 14:23:08 +0000,
Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
> 
> On 03/03/2026 13:13, Marc Zyngier wrote:
> > On Mon, 02 Mar 2026 17:13:41 +0000,
> > Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
> >> 
> >> More importantly, we have to make sure that the "RMI_PSCI_COMPLETE" is
> >> invoked before both of the following:
> >>    1. The "source" vCPU is run again
> >>    2. More importantly the "target" vCPU is run.
> > 
> > I don't understand why (1) is required. Once the VMM gets the request,
> 
> The underlying issue is, the RMM doesn't have the VCPU object for the
> "target" VCPU, to make the book keeping. Also, please note that for  a
> Realm, PSCI is emulated by the "RMM". Host is obviously notified of the
> "PSCI" changes via EXIT_PSCI (note, it is not SMCCC exit)
>  so that it can be in sync with the real state. And does have a say in
>  CPU_ON. So, before we return to running the "source" CPU,
> Host must provide the target VCPU object and its consent (via
> psci_status) to the RMM. This allows the RMM to emulate the PSCI
> request correctly and also at the same time keep its book keeping
> in tact (i.e., marking the Target VCPU as runnable or not).
> 
> When a "source" VCPU exits to the host with a PSCI_EXIT, the RMM
> marks the source VCPU has a pending PSCI operation, and
> RMI_PSCI_COMPLETE request ticks that off, making it runnable again.

Sure. What I don't get is what this has to happen on the source vcpu
thread. The RMM has absolutely no clue about that, and there should be
no impediment to letting the target vcpu do it as it starts.

Even better, you should be able to do that on the first thread that
reenters the guest, completely removing any RMM knowledge from the
PSCI handling in userspace.

If you can't do that, then please consider fixing the RMM to allow it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.