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

[Suzuki K Poulose]

On 03/03/2026 14:37, Marc Zyngier wrote:
> On Tue, 03 Mar 2026 14:23:08 +0000,
> Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
>>
>> On 03/03/2026 13:13, Marc Zyngier wrote:
>>> On Mon, 02 Mar 2026 17:13:41 +0000,
>>> Suzuki K Poulose <suzuki.poulose at arm.com> 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.

Because, the RMM wants to make that the state is consistent. i.e,
Host cannot lie to the "source" VCPU and RMM (e.g., CPU_ON denied) and
then run the "target" VCPU.

In other words, the response to the CPU_ON must be recorded by the RMM
in the target VCPU state, to make sure the target VCPU state is
consistent with the response.

The only way to fix this would be RMM keeping track of "mpidr" to REC
object mapping (VCPU object), which impacts the scalability. With that
in place, RMM can update the target VCPU state from the return of the
REC_ENTER after a PSCI_EXIT.

That said, will explore the options to address this

Thanks
Suzuki

> 
> 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.
>