From: Steven Price <steven.price@arm•com>
To: Marc Zyngier <maz@kernel•org>
Cc: kvm@vger•kernel.org, kvmarm@lists•linux.dev,
Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>, James Morse <james.morse@arm•com>,
Oliver Upton <oliver.upton@linux•dev>,
Suzuki K Poulose <suzuki.poulose@arm•com>,
Zenghui Yu <yuzenghui@huawei•com>,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, Joey Gouly <joey.gouly@arm•com>,
Alexandru Elisei <alexandru.elisei@arm•com>,
Christoffer Dall <christoffer.dall@arm•com>,
Fuad Tabba <tabba@google•com>,
linux-coco@lists•linux.dev,
Ganapatrao Kulkarni <gankulkarni@os•amperecomputing.com>,
Gavin Shan <gshan@redhat•com>,
Shanker Donthineni <sdonthineni@nvidia•com>,
Alper Gun <alpergun@google•com>,
"Aneesh Kumar K . V" <aneesh.kumar@kernel•org>,
Emi Kisanuki <fj0570is@fujitsu•com>,
Vishal Annapurve <vannapurve@google•com>,
WeiLin.Chang@arm•com, Lorenzo.Pieralisi2@arm•com
Subject: Re: [PATCH v14 04/44] arm64: RMI: Add SMC definitions for calling the RMM
Date: Wed, 3 Jun 2026 11:15:28 +0100 [thread overview]
Message-ID: <c217a495-bd39-408c-9040-010c30bed1e6@arm.com> (raw)
In-Reply-To: <87jysvahpb.wl-maz@kernel.org>
On 22/05/2026 10:58, Marc Zyngier wrote:
> On Thu, 21 May 2026 16:33:09 +0100,
> Steven Price <steven.price@arm•com> wrote:
>>
>> On 21/05/2026 13:40, Marc Zyngier wrote:
>>> On Wed, 13 May 2026 14:17:12 +0100,
>>> Steven Price <steven.price@arm•com> wrote:
>>>>
>>>> The RMM (Realm Management Monitor) provides functionality that can be
>>>> accessed by SMC calls from the host.
>>>>
>>>> The SMC definitions are based on DEN0137[1] version 2.0-bet1
>>>>
>>>> [1] https://developer.arm.com/documentation/den0137/2-0bet1/
>>>>
>>>> Signed-off-by: Steven Price <steven.price@arm•com>
>>>> ---
>>>> Changes since v13:
>>>> * Updated to RMM spec v2.0-bet1
>>>> Changes since v12:
>>>> * Updated to RMM spec v2.0-bet0
>>>> Changes since v9:
>>>> * Corrected size of 'ripas_value' in struct rec_exit. The spec states
>>>> this is an 8-bit type with padding afterwards (rather than a u64).
>>>> Changes since v8:
>>>> * Added RMI_PERMITTED_GICV3_HCR_BITS to define which bits the RMM
>>>> permits to be modified.
>>>> Changes since v6:
>>>> * Renamed REC_ENTER_xxx defines to include 'FLAG' to make it obvious
>>>> these are flag values.
>>>> Changes since v5:
>>>> * Sorted the SMC #defines by value.
>>>> * Renamed SMI_RxI_CALL to SMI_RMI_CALL since the macro is only used for
>>>> RMI calls.
>>>> * Renamed REC_GIC_NUM_LRS to REC_MAX_GIC_NUM_LRS since the actual
>>>> number of available list registers could be lower.
>>>> * Provided a define for the reserved fields of FeatureRegister0.
>>>> * Fix inconsistent names for padding fields.
>>>> Changes since v4:
>>>> * Update to point to final released RMM spec.
>>>> * Minor rearrangements.
>>>> Changes since v3:
>>>> * Update to match RMM spec v1.0-rel0-rc1.
>>>> Changes since v2:
>>>> * Fix specification link.
>>>> * Rename rec_entry->rec_enter to match spec.
>>>> * Fix size of pmu_ovf_status to match spec.
>>>> ---
>>>> arch/arm64/include/asm/rmi_smc.h | 448 +++++++++++++++++++++++++++++++
>>>> 1 file changed, 448 insertions(+)
>>>> create mode 100644 arch/arm64/include/asm/rmi_smc.h
>>>>
>>>> diff --git a/arch/arm64/include/asm/rmi_smc.h b/arch/arm64/include/asm/rmi_smc.h
>>>> new file mode 100644
>>>> index 000000000000..a09b7a631fef
>>>> --- /dev/null
>>>> +++ b/arch/arm64/include/asm/rmi_smc.h
>>>> @@ -0,0 +1,448 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +/*
>>>> + * Copyright (C) 2023-2026 ARM Ltd.
>>>> + *
>>>> + * The values and structures in this file are from the Realm Management Monitor
>>>> + * specification (DEN0137) version 2.0-bet1:
>>>> + * https://developer.arm.com/documentation/den0137/2-0bet1/
>>>
>>> How long is this spec going to be available on the ARM web site, which
>>> has a tendency of being reorganised every other week? And there is
>>> already a beta2.
>>
>> Obviously I can't predict the next reorganisation - but at least it's a
>> link that could be fed into archive.org or similar.
>
> I found that the PDF spec was less susceptible to creative nonsense,
> and people can download it for future reference, whereas ARM has
> happily *deleted* specs from the website over time (try to find PSCI
> 0.1, for example...).
Sadly the nearest I found to a link directly to the PDF is:
https://documentation-service.arm.com/static/69cb945ac1586b7c59b1c00c
But I have 0 confidence that that link will work for long (if indeed it
even works for others now!). If you know of any way of getting a better
link out of the Arm website that I'm all ears!
> [...]
>
>>>> +struct realm_params {
>>>> + union { /* 0x0 */
>>>> + struct {
>>>> + u64 flags;
>>>> + u64 s2sz;
>>>> + u64 sve_vl;
>>>> + u64 num_bps;
>>>> + u64 num_wps;
>>>> + u64 pmu_num_ctrs;
>>>> + u64 hash_algo;
>>>> + u64 num_aux_planes;
>>>> + };
>>>> + u8 padding0[0x400];
>>>
>>> SZ_1K? And similarly all over the shop?
>>
>> I'm a bit less sure that makes the code more readable - these structures
>> are a bit of a pain because they are somewhat sparse. I've left a
>> comment where the beginning of each union is, and personally I find it
>> easier to see 0x0 + 0x400 == 0x400 rather than trying to work out what
>> SZ_1K is in hex. This is particularly the case in terms of:
>>
>>> struct rec_params {
>>> union { /* 0x0 */
>>> u64 flags;
>>> u8 padding0[0x100];
>>> };
>>> union { /* 0x100 */
>>> u64 mpidr;
>>> u8 padding1[0x100];
>>> };
>>> union { /* 0x200 */
>>> u64 pc;
>>> u8 padding2[0x100];
>>> };
>>> union { /* 0x300 */
>>> u64 gprs[REC_CREATE_NR_GPRS];
>>> u8 padding3[0xd00];
>>> };
>>> };
>>
>> Where 0xd00 doesn't even have a correspoding SZ_ define.
>
> Indeed, but it is (SZ_4K - SZ_256 * 3).
Do you really think
u8 padding3[SZ_4K - SZ_256 * 3];
is better? I certainly don't. I'll give you (SZ_4K - 0x300) is tempting.
Although it then makes the BUILD_BUG_ON idea below somewhat pointless.
> And a lot of these structures> seem to be designed to form a 4kB blob.
I'm sure we can make use of
> that information (BUILD_BUG_ON?).
BUILD_BUG_ON requires being in a function. But static_assert() can be
used in the header by the struct definitions - I'll add that, thanks for
the suggestion.
>>
>> The RMM deals with this with macro magic:
>>
>>> struct rmi_rec_params {
>>> /* Flags */
>>> SET_MEMBER_RMI(unsigned long flags, 0, 0x100); /* Offset 0 */
>>> /* MPIDR of the REC */
>>> SET_MEMBER_RMI(unsigned long mpidr, 0x100, 0x200); /* 0x100 */
>>> /* Program counter */
>>> SET_MEMBER_RMI(unsigned long pc, 0x200, 0x300); /* 0x200 */
>>> /* General-purpose registers */
>>> SET_MEMBER_RMI(unsigned long gprs[REC_CREATE_NR_GPRS], 0x300, 0x1000); /* 0x300 */
>>> };
>>
>> where the offsets are just directly encoded in the macro - but it's not
>> an especially robust macro and I'm not convinced it's more readable.
>
> I think this is just as horrible, but at least it seems to take the
> boundaries of the structure into account.
>
>>
>> I'm happy to hear other suggestions on how to encode this neatly.
>
> Honestly, I wouldn't mind having the structures described in a more
> abstract way and then pre-processed to generate the include files. If
> the architectural MRS wasn't so huge, I would have added it to the
> kernel and used that directly for KVM.
>
>>
>>> I haven't checked the details of the encodings (life is too short),
>>> but I wonder how much of this exists as an MRS and could be
>>> automatically generated?
>>
>> Automatically generating this would be good - I'm not sure whether we
>> have a (public) source available to generate from at the moment. I have
>> tried to methodically work through the spec when updating this file, but
>> as Gavin has already pointed out there was at least one mistake (in
>> currently unused definitions) this time.
>
> I'm slightly baffled that even the RMM is written this way. Given the
> formalism used in the RMM spec, I was expecting that you'd have a
> bunch of JSON at hand and able to generate any output from that. Doing
> this stuff by hand is both incredibly dull work *and* extremely error
> prone.
I'll look into the possibility of generating the headers. While dull and
error prone I have found it is sometimes useful for forcing a review of
the spec itself. There have been a number of bugs I've found (and have
been corrected) in the spec while writing the header files - it's very
easy to skim read those parts of the document otherwise.
Writing the structures out in a "more abstract way" might be a good
idea, but I'm just a little wary of writing another tool which is only
used in this one spot. The RMM structures are somewhat unusual in being
so sparse.
Thanks,
Steve
> Thanks,
>
> M.
>
next prev parent reply other threads:[~2026-06-03 10:15 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 13:17 [PATCH v14 00/44] arm64: Support for Arm CCA in KVM Steven Price
2026-05-13 13:17 ` [PATCH v14 01/44] kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h Steven Price
2026-05-21 10:19 ` Marc Zyngier
2026-05-21 15:11 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 02/44] kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Steven Price
2026-05-21 10:26 ` Marc Zyngier
2026-05-21 15:11 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 03/44] arm64: RME: Handle Granule Protection Faults (GPFs) Steven Price
2026-05-21 12:25 ` Marc Zyngier
2026-05-21 15:15 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 04/44] arm64: RMI: Add SMC definitions for calling the RMM Steven Price
2026-05-18 7:08 ` Gavin Shan
2026-05-20 16:01 ` Steven Price
2026-05-21 12:40 ` Marc Zyngier
2026-05-21 14:50 ` Suzuki K Poulose
2026-05-21 15:33 ` Steven Price
2026-05-22 9:58 ` Marc Zyngier
2026-06-03 10:15 ` Steven Price [this message]
2026-05-13 13:17 ` [PATCH v14 05/44] arm64: RMI: Add wrappers for RMI calls Steven Price
2026-05-19 5:35 ` Aneesh Kumar K.V
2026-05-21 15:44 ` Steven Price
2026-05-21 0:21 ` Gavin Shan
2026-05-21 15:44 ` Steven Price
2026-05-21 12:49 ` Marc Zyngier
2026-05-21 15:44 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 06/44] arm64: RMI: Check for RMI support at init Steven Price
2026-05-21 0:39 ` Gavin Shan
2026-05-21 15:49 ` Steven Price
2026-05-25 6:58 ` Gavin Shan
2026-06-03 10:57 ` Steven Price
2026-05-21 13:02 ` Marc Zyngier
2026-06-03 10:57 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 07/44] arm64: RMI: Configure the RMM with the host's page size Steven Price
2026-05-21 0:51 ` Gavin Shan
2026-05-21 22:36 ` Suzuki K Poulose
2026-05-21 13:30 ` Marc Zyngier
2026-05-21 14:53 ` Suzuki K Poulose
2026-06-03 15:48 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 08/44] arm64: RMI: Ensure that the RMM has GPT entries for memory Steven Price
2026-05-19 5:55 ` Aneesh Kumar K.V
2026-06-03 15:48 ` Steven Price
2026-05-21 0:58 ` Gavin Shan
2026-06-03 15:48 ` Steven Price
2026-05-21 13:47 ` Marc Zyngier
2026-05-21 14:24 ` Marc Zyngier
2026-05-21 15:39 ` Suzuki K Poulose
2026-06-03 15:48 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 09/44] arm64: RMI: Provide functions to delegate/undelegate ranges of memory Steven Price
2026-05-21 13:59 ` Marc Zyngier
2026-05-21 16:01 ` Suzuki K Poulose
2026-05-22 10:02 ` Marc Zyngier
2026-06-04 14:43 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 10/44] arm64: RMI: Add support for SRO Steven Price
2026-05-14 8:01 ` Aneesh Kumar K.V
2026-05-14 9:33 ` Steven Price
2026-05-19 6:02 ` Aneesh Kumar K.V
2026-06-04 15:19 ` Steven Price
2026-05-21 4:38 ` Gavin Shan
2026-06-04 15:19 ` Steven Price
2026-05-21 14:35 ` Marc Zyngier
2026-06-04 15:19 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 11/44] arm64: RMI: Check for RMI support at KVM init Steven Price
2026-05-13 13:17 ` [PATCH v14 12/44] arm64: RMI: Check for LPA2 support Steven Price
2026-05-13 13:17 ` [PATCH v14 13/44] arm64: RMI: Define the user ABI Steven Price
2026-05-26 22:17 ` Wei-Lin Chang
2026-06-04 15:27 ` Steven Price
2026-05-27 15:21 ` Marc Zyngier
2026-06-02 11:15 ` Suzuki K Poulose
2026-06-04 15:27 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 14/44] arm64: RMI: Basic infrastructure for creating a realm Steven Price
2026-05-19 6:31 ` Aneesh Kumar K.V
2026-05-28 7:10 ` Marc Zyngier
2026-06-02 14:49 ` Suzuki K Poulose
2026-06-04 15:55 ` Steven Price
2026-05-13 13:17 ` [PATCH v14 15/44] kvm: arm64: Don't expose unsupported capabilities for realm guests Steven Price
2026-05-13 13:17 ` [PATCH v14 16/44] KVM: arm64: Allow passing machine type in KVM creation Steven Price
2026-05-13 13:17 ` [PATCH v14 17/44] arm64: RMI: RTT tear down Steven Price
2026-05-19 6:54 ` Aneesh Kumar K.V
2026-05-26 22:27 ` Wei-Lin Chang
2026-05-26 22:32 ` Wei-Lin Chang
2026-05-13 13:17 ` [PATCH v14 18/44] arm64: RMI: Activate realm on first VCPU run Steven Price
2026-05-13 13:17 ` [PATCH v14 19/44] arm64: RMI: Allocate/free RECs to match vCPUs Steven Price
2026-05-26 22:39 ` Wei-Lin Chang
2026-05-13 13:17 ` [PATCH v14 20/44] arm64: RMI: Support for the VGIC in realms Steven Price
2026-05-28 4:07 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 21/44] KVM: arm64: Support timers in realm RECs Steven Price
2026-05-28 4:11 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 22/44] arm64: RMI: Handle realm enter/exit Steven Price
2026-05-28 4:38 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 23/44] arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE Steven Price
2026-05-19 9:40 ` Aneesh Kumar K.V
2026-05-27 10:52 ` Wei-Lin Chang
2026-05-13 13:17 ` [PATCH v14 24/44] KVM: arm64: Handle realm MMIO emulation Steven Price
2026-05-28 5:03 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 25/44] KVM: arm64: Expose support for private memory Steven Price
2026-05-13 13:17 ` [PATCH v14 26/44] arm64: RMI: Allow populating initial contents Steven Price
2026-05-28 5:30 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 27/44] arm64: RMI: Set RIPAS of initial memslots Steven Price
2026-05-19 10:02 ` Aneesh Kumar K.V
2026-05-19 10:13 ` Suzuki K Poulose
2026-05-19 12:55 ` Aneesh Kumar K.V
2026-05-19 13:06 ` Suzuki K Poulose
2026-05-13 13:17 ` [PATCH v14 28/44] arm64: RMI: Create the realm descriptor Steven Price
2026-05-26 22:47 ` Wei-Lin Chang
2026-05-28 5:51 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory Steven Price
2026-05-13 13:17 ` [PATCH v14 30/44] KVM: arm64: Handle realm VCPU load Steven Price
2026-05-13 13:17 ` [PATCH v14 31/44] KVM: arm64: Validate register access for a Realm VM Steven Price
2026-05-13 13:17 ` [PATCH v14 32/44] KVM: arm64: Handle Realm PSCI requests Steven Price
2026-05-28 6:55 ` Gavin Shan
2026-05-13 13:17 ` [PATCH v14 33/44] KVM: arm64: WARN on injected undef exceptions Steven Price
2026-05-13 13:17 ` [PATCH v14 34/44] arm64: RMI: allow userspace to inject aborts Steven Price
2026-05-13 13:17 ` [PATCH v14 35/44] arm64: RMI: support RSI_HOST_CALL Steven Price
2026-05-13 13:17 ` [PATCH v14 36/44] arm64: RMI: Allow checking SVE on VM instance Steven Price
2026-05-13 13:17 ` [PATCH v14 37/44] arm64: RMI: Prevent Device mappings for Realms Steven Price
2026-05-19 10:25 ` Aneesh Kumar K.V
2026-05-13 13:17 ` [PATCH v14 38/44] arm64: RMI: Propagate number of breakpoints and watchpoints to userspace Steven Price
2026-05-13 13:17 ` [PATCH v14 39/44] arm64: RMI: Set breakpoint parameters through SET_ONE_REG Steven Price
2026-05-13 13:17 ` [PATCH v14 40/44] arm64: RMI: Propagate max SVE vector length from RMM Steven Price
2026-05-13 13:17 ` [PATCH v14 41/44] arm64: RMI: Configure max SVE vector length for a Realm Steven Price
2026-05-13 13:17 ` [PATCH v14 42/44] arm64: RMI: Provide register list for unfinalized RMI RECs Steven Price
2026-05-13 13:17 ` [PATCH v14 43/44] arm64: RMI: Provide accurate register list Steven Price
2026-05-13 13:17 ` [PATCH v14 44/44] arm64: RMI: Enable realms to be created Steven Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c217a495-bd39-408c-9040-010c30bed1e6@arm.com \
--to=steven.price@arm$(echo .)com \
--cc=Lorenzo.Pieralisi2@arm$(echo .)com \
--cc=WeiLin.Chang@arm$(echo .)com \
--cc=alexandru.elisei@arm$(echo .)com \
--cc=alpergun@google$(echo .)com \
--cc=aneesh.kumar@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=christoffer.dall@arm$(echo .)com \
--cc=fj0570is@fujitsu$(echo .)com \
--cc=gankulkarni@os$(echo .)amperecomputing.com \
--cc=gshan@redhat$(echo .)com \
--cc=james.morse@arm$(echo .)com \
--cc=joey.gouly@arm$(echo .)com \
--cc=kvm@vger$(echo .)kernel.org \
--cc=kvmarm@lists$(echo .)linux.dev \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-coco@lists$(echo .)linux.dev \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=maz@kernel$(echo .)org \
--cc=oliver.upton@linux$(echo .)dev \
--cc=sdonthineni@nvidia$(echo .)com \
--cc=suzuki.poulose@arm$(echo .)com \
--cc=tabba@google$(echo .)com \
--cc=vannapurve@google$(echo .)com \
--cc=will@kernel$(echo .)org \
--cc=yuzenghui@huawei$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox