From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Gavin Shan <gshan@redhat.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev
Cc: maz@kernel.org, will@kernel.org, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
aneesh.kumar@kernel.org, oupton@kernel.org, joey.gouly@arm.com,
tabba@google.com, yuzenghui@huawei.com,
linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com,
sdonthineni@nvidia.com, alpergun@google.com,
fj0570is@fujitsu.com, WeiLin.Chang@arm.com,
lpieralisi@kernel.org, enju.kohei@fujitsu.com
Subject: Re: [PATCH v17 1/7] firmware: arm_rmm: Add SMC definitions for calling the RMM
Date: Thu, 10 Sep 2026 10:54:47 +0100 [thread overview]
Message-ID: <6aa14157-1542-445b-99bc-61a4e14a7864@arm.com> (raw)
In-Reply-To: <7223aeec-b269-4ef5-b5b9-693d4d12afd1@redhat.com>
On 10/09/2026 10:47, Gavin Shan wrote:
> On 9/9/26 6:39 PM, Suzuki K Poulose wrote:
>> On 08/09/2026 23:41, Gavin Shan wrote:
>>> On 9/8/26 8:37 PM, Suzuki K Poulose wrote:
>>>> On 08/09/2026 07:19, Gavin Shan wrote:
>>>>> On 9/7/26 7:59 PM, Suzuki K Poulose wrote:
>>>>>> From: Steven Price <steven.price@arm.com>
>>>>>>
>>>>>> 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-bet3
>>>>>>
>>>>>> [1] https://developer.arm.com/documentation/den0137/2-0bet3/
>>>>>>
>>>>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>>
>>>> ...
>>>>
>>>>>> ---
>>>>>> include/linux/arm-smccc-rmi.h | 494 ++++++++++++++++++++++++++++
>>>>>> ++ ++++
>>>>>> 1 file changed, 494 insertions(+)
>>>>>> create mode 100644 include/linux/arm-smccc-rmi.h
>>>>>>
>>>>>
>>>>> Some nitpicks below, please pick up the commits that look
>>>>> reasonable :)
>>>>>
>>>>
>>>>
>>>>>> +
>>>>>> +#define RMI_RETURN_STATUS_MASK (0xFFUL)
>>>>>> +#define RMI_RETURN_INDEX_MASK (0xFFUL << 8)
>>>>>> +#define RMI_RETURN_MEMREQ_MASK (0x3UL << 8)
>>>>>> +#define RMI_RETURN_CAN_CANCEL_MASK (0x1UL << 10)
>>>>>> +
>>>>>> +#define RMI_RETURN_STATUS(ret) FIELD_GET(RMI_RETURN_STATUS_MASK,
>>>>>> ret)
>>>>>> +#define RMI_RETURN_INDEX(ret) FIELD_GET(RMI_RETURN_INDEX_MASK, ret)
>>>>>> +#define RMI_RETURN_MEMREQ(ret) FIELD_GET(RMI_RETURN_MEMREQ_MASK,
>>>>>> ret)
>>>>>> +#define RMI_RETURN_CAN_CANCEL(ret)
>>>>>> FIELD_GET(RMI_RETURN_CAN_CANCEL_MASK, ret)
>>>>>> +
>>>>>
>>>>> If I'm correct enough, RMI_RETURN_{STATUS, INDEX, MEMREQ,
>>>>> CAN_CANEL} _MASK are used
>>>>> for once in this header file. So we needn't explicitly expose them
>>>>> and combine their
>>>>> definitions with users to fetch the corresponding fields, as below.
>>>>>
>>>>> #define RMI_RETURN_STATUS(ret) FIELD_GET(GENMASK(7, 0), ret)
>>>>> #define RMI_RETURN_INDEX(ret) FIELD_GET(GENMASK(15, 8), ret)
>>>>> #define RMI_RETURN_MEMREQ(ret) FIELD_GET(GENMASK(10, 8), ret)
>>>>> #define RMI_RETURN_CAN_CANCEL(ret) FIELD_GEt(GENMASK(10, 10), ret)
>>>>
>>>> I belive the header files were generated from a tool (by Steven) and
>>>> these would make it easier to compare with the generated header file
>>>> for
>>>> any deviation from the spec. So, I am a bit reluctant make these
>>>> changes.
>>>>
>>>> That said, I am happy to convert the mask definitions to GENMASK() for
>>>> consistency and readability. i.e., something like:
>>>>
>>>> diff --git a/include/linux/arm-smccc-rmi.h b/include/linux/arm-
>>>> smccc- rmi.h
>>>> index 3eb88caf40964..078197284415e 100644
>>>> --- a/include/linux/arm-smccc-rmi.h
>>>> +++ b/include/linux/arm-smccc-rmi.h
>>>> @@ -139,10 +139,10 @@
>>>> #define RMI_ABI_VERSION_GET_MINOR(version) ((version) & 0xFFFF)
>>>> #define RMI_ABI_VERSION(major, minor) (((major) << 16) |
>>>> (minor))
>>>>
>>>> -#define RMI_RETURN_STATUS_MASK (0xFFUL)
>>>> -#define RMI_RETURN_INDEX_MASK (0xFFUL << 8)
>>>> -#define RMI_RETURN_MEMREQ_MASK (0x3UL << 8)
>>>> -#define RMI_RETURN_CAN_CANCEL_MASK (0x1UL << 10)
>>>> +#define RMI_RETURN_STATUS_MASK GENMASK(7, 0)
>>>> +#define RMI_RETURN_INDEX_MASK GENMASK(15, 8)
>>>> +#define RMI_RETURN_MEMREQ_MASK GENMASK(10, 8)
>>>> +#define RMI_RETURN_CAN_CANCEL_MASK BIT(10)
>>>>
>>>
>>> Ok.
>>>
>>>>>
>>>>>> +#define RMI_SUCCESS 0
>>>>>> +#define RMI_ERROR_INPUT 1
>>>>>> +#define RMI_ERROR_REALM 2
>>>>>> +#define RMI_ERROR_REC 3
>>>>>> +#define RMI_ERROR_RTT 4
>>>>>> +#define RMI_ERROR_NOT_SUPPORTED 5
>>>>>> +#define RMI_ERROR_DEVICE 6
>>>>>> +#define RMI_ERROR_RTT_AUX 7
>>>>>> +#define RMI_ERROR_PSMMU_ST 8
>>>>>> +#define RMI_ERROR_DPT 9
>>>>>> +#define RMI_BUSY 10
>>>>>> +#define RMI_ERROR_GLOBAL 11
>>>>>> +#define RMI_ERROR_TRACKING 12
>>>>>> +#define RMI_INCOMPLETE 13
>>>>>> +#define RMI_BLOCKED 14
>>>>>> +#define RMI_ERROR_GPT 15
>>>>>> +#define RMI_ERROR_GRANULE 16
>>>>>> +
>>>>>> +#define RMI_CONTINUE_KEEP_GOING 0
>>>>>> +#define RMI_CONTINUE_STOP 1
>>>>>> +
>>>>>> +#define RMI_OP_MEM_REQ_NONE 0
>>>>>> +#define RMI_OP_MEM_REQ_DONATE 1
>>>>>> +#define RMI_OP_MEM_REQ_RECLAIM 2
>>>>>> +
>>>>>> +#define RMI_DONATE_SIZE_MASK 3UL
>>>>>> +#define RMI_DONATE_COUNT_MASK GENMASK(15, 2)
>>>>>> +#define RMI_DONATE_CONTIG_MASK BIT(16)
>>>>>> +#define RMI_DONATE_STATE_MASK GENMASK(18, 17)
>>>>>> +
>>>>>> +#define RMI_DONATE_SIZE(req)
>>>>>> FIELD_GET(RMI_DONATE_SIZE_MASK, req)
>>>>>> +#define RMI_DONATE_COUNT(req) FIELD_GET(RMI_DONATE_COUNT_MASK, req)
>>>>>> +#define RMI_DONATE_CONTIG(req) FIELD_GET(RMI_DONATE_CONTIG_MASK,
>>>>>> req)
>>>>>> +#define RMI_DONATE_STATE(req) FIELD_GET(RMI_DONATE_STATE_MASK, req)
>>>>>> +
>>>>>
>>>>> As above, RMI_DONATE_{SIZE, COUNT, CONTIG, STATE}_MASK are used for
>>>>> once in this
>>>>> header file. So their definitions can be dropped by modifying the
>>>>> followup macros,
>>>>> as below. Some enhancements are also applicable: (a) Use 'BLOCK' to
>>>>> indicate the
>>>>> unit encoded in the request. (b) The macros are put into order from
>>>>> MSB to LSB.
>>>>>
>>>>> #define RMI_DONATE_STATE(req) FIELD_GET(GENMASK(18, 17), req)
>>>>> #define RMI_DONATE_CONTIG(req) FIELD_GET(GENMASK(16, 16), req)
>>>>> #define RMI_DONATE_BLOCK_COUNT(req) FIELD_GET(GENMASK(15, 2), req)
>>>>> #define RMI_DONATE_BLOCK_SIZE(req) FIELD_GET(GENMASK(1, 0), req)
>>>>
>>>> Same as above.
>>>>
>>>
>>> Please rename RMI_DONATE_{SIZE, COUNT} to RMI_DONATE_BLOCK_{SIZE,
>>> COUNT} if possible.
>>
>> Sorry, forgot to add that, I have renamed RMI_{DONATE,ADDR_RANGE}_SIZE
>> => RMI_{*}_BLOCK_SIZE, left the _COUNT as it is.
>>
>
> It's ok to me. The point is to have "BLOCK", indicating it's related to
> a block. In rmi.c, 'unit' is also used and needs to be replaced with
> 'block',
> consistent with the spec.
Yep, I could see why Steven went with "unit". But I have replaced them
with block everywhere to be consistent with the spec.
Cheers
Suzuki
next prev parent reply other threads:[~2026-09-10 9:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 9:59 [PATCH v17 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Suzuki K Poulose
2026-09-07 9:59 ` [PATCH v17 1/7] firmware: arm_rmm: Add SMC definitions for calling the RMM Suzuki K Poulose
2026-09-08 6:19 ` Gavin Shan
2026-09-08 10:37 ` Suzuki K Poulose
2026-09-08 22:41 ` Gavin Shan
2026-09-09 8:39 ` Suzuki K Poulose
2026-09-10 9:47 ` Gavin Shan
2026-09-10 9:54 ` Suzuki K Poulose [this message]
2026-09-07 9:59 ` [PATCH v17 2/7] firmware: arm_rmm: Check for RMI support at init Suzuki K Poulose
2026-09-08 6:46 ` Gavin Shan
2026-09-08 9:49 ` Suzuki K Poulose
2026-09-07 9:59 ` [PATCH v17 3/7] firmware: arm_rmm: Configure the RMM with the host's page size Suzuki K Poulose
2026-09-07 10:14 ` sashiko-bot
2026-09-07 12:02 ` Suzuki K Poulose
2026-09-07 22:40 ` Gavin Shan
2026-09-08 9:58 ` Suzuki K Poulose
2026-09-08 7:04 ` Gavin Shan
2026-09-08 8:00 ` Kohei Enju
2026-09-08 10:59 ` Gavin Shan
2026-09-09 2:01 ` Kohei Enju
2026-09-08 10:43 ` Suzuki K Poulose
2026-09-07 9:59 ` [PATCH v17 4/7] firmware: arm_rmm: Add support for SRO Suzuki K Poulose
2026-09-07 10:14 ` sashiko-bot
2026-09-08 22:10 ` Suzuki K Poulose
2026-09-09 4:10 ` Gavin Shan
2026-09-10 9:51 ` Suzuki K Poulose
2026-09-11 15:29 ` Suzuki K Poulose
2026-09-07 9:59 ` [PATCH v17 5/7] firmware: arm_rmm: Activate the RMM Suzuki K Poulose
2026-09-07 10:17 ` sashiko-bot
2026-09-07 16:16 ` Suzuki K Poulose
2026-09-09 4:29 ` Gavin Shan
2026-09-09 8:25 ` Suzuki K Poulose
2026-09-07 9:59 ` [PATCH v17 6/7] firmware: arm_rmm: Ensure the RMM has GPT entries for memory Suzuki K Poulose
2026-09-09 6:40 ` Gavin Shan
2026-09-09 8:33 ` Suzuki K Poulose
2026-09-07 9:59 ` [PATCH v17 7/7] firmware: arm_rmm: Add wrappers for Realm related RMI commands Suzuki K Poulose
2026-09-07 10:10 ` sashiko-bot
2026-09-07 12:20 ` Suzuki K Poulose
2026-09-09 7:15 ` Gavin Shan
2026-09-09 8:55 ` Suzuki K Poulose
2026-09-08 4:09 ` [PATCH v17 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Kohei Enju
2026-09-08 5:46 ` Suzuki K Poulose
2026-09-08 7:30 ` Kohei Enju
2026-09-09 10:52 ` Gavin Shan
2026-09-10 4:51 ` Kohei Enju
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=6aa14157-1542-445b-99bc-61a4e14a7864@arm.com \
--to=suzuki.poulose@arm.com \
--cc=WeiLin.Chang@arm.com \
--cc=alpergun@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=enju.kohei@fujitsu.com \
--cc=fj0570is@fujitsu.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=gshan@redhat.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sdonthineni@nvidia.com \
--cc=steven.price@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.