Hi Marc,
On 21/03/2026 13:21, Marc Zyngier wrote:
> On Wed, 18 Mar 2026 15:53:29 +0000,
> Steven Price <steven.price@arm.com> wrote:
>>
>> Not all the functionality has been migrated to the v2.0 specification,
>> so for now we still rely on some v1.0 SMCs. This mixture is not
>> spec-compliant, but is necessary until an updated RMM is available.
>>
>
> This sort of things really makes it awkward to review the series.
I agree, that this makes it painful to review as it doesn't get you a
clear picture of what will stay or what will change and is not the best
use of the precious time of the Maintainers. We will make sure to flag
the appropriate portions in the next iteration. Apologies!
>
> Do you really expect the reviewers to mentally triage what is current
> and what is only throwaway code? I want to see patches that are merge
> candidates, not patches that are only there to cope with the broken
> state of the RMM.
Agree, we could clearly mark the "areas" of code that we anticipate to
change and by the next posting this will be clearly marked.
> If extra hacks are required to work with the current Franken-RMM, keep
> them as a separate series that doesn't pollute what is targeted at
> upstream.
In fact there are only a few areas that would change with a true RMM-
v2.0 spec compliant firmware. But yes, I acknowledge that feedback from
the maintainers would be fedback to the RMM spec and this might trigger
minor changes to align with them.
>
> It also means that any testing you have done will be invalidated when
> the one true RMM shows up...
Agreed, True, but not very much of the functionality/
spec are changing until we land in fully compliant 2.0 RMM.
See more on this below.
>
> "This is great."
>
> M.
> diff --git a/arch/arm64/include/asm/rmi_smc.h b/arch/arm64/include/asm/rmi_smc.h
> index 8a42b83218f8..049d71470486 100644
> --- a/arch/arm64/include/asm/rmi_smc.h
> +++ b/arch/arm64/include/asm/rmi_smc.h
> @@ -30,14 +30,15 @@
> #define SMC_RMI_REC_ENTER SMC_RMI_CALL(0x015c)
> #define SMC_RMI_RTT_CREATE SMC_RMI_CALL(0x015d)
> #define SMC_RMI_RTT_DESTROY SMC_RMI_CALL(0x015e)
> +#define SMC_RMI_RTT_MAP_UNPROTECTED SMC_RMI_CALL(0x015f) //
>
> #define SMC_RMI_RTT_READ_ENTRY SMC_RMI_CALL(0x0161)
> -
> +#define SMC_RMI_RTT_UNMAP_UNPROTECTED SMC_RMI_CALL(0x0162) //
The above two RMI commands help with mapping/unmapping Unprotected
memory and will be replaced with two renamed commands with "Range based"
ABI => SMC_RMI_RTT_UNPROT_{MAP,UNMAP}. So, as far as the KVM code is
concerned, we do the mapping a granule at a time (without hugetlb
support) and this is simply a change in the command in the true 2.0 RMM.
> #define SMC_RMI_RTT_DEV_VALIDATE SMC_RMI_CALL(0x0163)
> #define SMC_RMI_PSCI_COMPLETE SMC_RMI_CALL(0x0164)
> #define SMC_RMI_FEATURES SMC_RMI_CALL(0x0165)
> #define SMC_RMI_RTT_FOLD SMC_RMI_CALL(0x0166)
> -
> +#define SMC_RMI_REC_AUX_COUNT SMC_RMI_CALL(0x0167) //
This is part of the REC creation, where we donate AUXilliary granules
for the VCPU to save state. This is replaced by the SRO method, which we
have a WIP path at the top of the series and it will be cleaned up in
the next version.
We wanted to send this version out which is the first one with RMM-v2.0
spec, which has addressed the concerns and feedback around the RMM-v1.0
spec. But we have clearly felt short of marking "what is volatile" and
what is stable, to help the review. We will address this in the next
iteration.
Thanks for taking the time to respond.
Kind regards
Suzuki