All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: Suzuki K Poulose <suzuki.poulose@arm.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: Wed, 9 Sep 2026 08:41:23 +1000	[thread overview]
Message-ID: <52e58930-8fa4-4c75-981c-25be42d83f2d@redhat.com> (raw)
In-Reply-To: <aca629b2-27a0-4c47-acac-87edb3b0d3d9@arm.com>

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.

>>
>>> +#define RMI_OP_MEM_DELEGATED        0
>>> +#define RMI_OP_MEM_UNDELEGATED        1
>>> +#define RMI_OP_MEM_CONDITIONAL        2
>>> +
>>
>> B4.6.40 RmiOpMemContig type is missed here and they should be used in the c code.
>>
>> #define RMI_OP_MEM_NON_CONTIG    0
>> #define RMI_OP_MEM_CONTIG    1
>>
>> In the c code, we shall have:
>>
>> if (RMI_DONATE_CONTIG(req) == RMI_OP_MEM_CONTIG)) {
>>     ...
>> } else {
>>     ...
>> }
>>
> 
> Does it make much sense though ? I prefer
> 
> if (RMI_DONATE_CONTIG(req))
> 
> to
> 
> 
> if (RMI_DONATE_CONTIG(req) == RMI_OP_MEM_CONTIG)) {
> 
> 
> than having a field for a single bit values. I am happy to change
> this if there is strong preference to the other.
> 

The point is RMM-v2.0-bet3 expose RMI_OP_{MEM, MEM_NON}_CONTIG instead of true/false
to indicate if the requested memory blocks are physically contiguous or not. So the
expression 'if (RMI_DONATE_CONTIG(req) == RMI_OP_MEM_CONTIG)' is consistent to the
RMM-v2.0-bet3 spec.

  
>> Similarly, B4.6.39 RmiOpCanCancel type is missed here and they should be used in
>> the c code.
>>
>> #define RMI_OP_CANNOT_CANCEL    0
>> #define RMI_OP_CAN_CANCEL    1
>>
>> In the c code, we shall have:
>>
>> if (RMI_RETURN_CAN_CANCEL(ret) == RMI_OP_CAN_CANCEL) {
>>      ...
>> } else {
>>      ...
>> }
>>
> 
> Same as above.
> 

Please see above explanation.

>>> +#define RMI_ADDR_TYPE_NONE        0
>>> +#define RMI_ADDR_TYPE_SINGLE        1
>>> +#define RMI_ADDR_TYPE_LIST        2
>>> +
>>> +#define RMI_ADDR_RANGE_SIZE_MASK    GENMASK(1, 0)
>>> +#define RMI_ADDR_RANGE_COUNT_MASK    GENMASK(PAGE_SHIFT - 1, 2)
>>> +#define RMI_ADDR_RANGE_ADDR_MASK    (PAGE_MASK & GENMASK(51, 0))
>>> +#define RMI_ADDR_RANGE_STATE_MASK    GENMASK(63, 62)
>>> +
>>> +#define RMI_ADDR_RANGE_SIZE(ar) (FIELD_GET(RMI_ADDR_RANGE_SIZE_MASK, \
>>> +                           (ar)))
>>> +#define RMI_ADDR_RANGE_COUNT(ar) (FIELD_GET(RMI_ADDR_RANGE_COUNT_MASK, \
>>> +                           (ar)))
>>> +#define RMI_ADDR_RANGE_ADDR(ar)        ((ar) & RMI_ADDR_RANGE_ADDR_MASK)
>>> +#define RMI_ADDR_RANGE_STATE(ar) (FIELD_GET(RMI_ADDR_RANGE_STATE_MASK, \
>>> +                           (ar)))
>>> +
>>
>> I guess it wouldn't a bad idea to explictly indicate 'BLOCK' in the definitions, as
>> below. Some improvements are applicated either: (a) 'ar' is renamed to 'r'; (b) The
>> excessive parentheses are dropped to follow the patterns we already had; (c) For
>> RMI_ADDR_RANGE_ADDR(r), FIELD_GET() is used.
>>
>> #define RMI_ADDR_RANGE_BLOCK_SIZE_MASK        GENMASK(1, 0)
>> #define RMI_ADDR_RANGE_BLOCK_COUNT_MASK        GENMASK(PAGE_SHIFT - 1, 2)
>> #define RMI_ADDR_RANGE_ADDR_MASK        (PAGE_MASK & GENMASK(51, 0))
>> #define RMI_ADDR_RANGE_STATE_MASK        GENMASK(63, 62)
>>
>> #define RMI_ADDR_RANGE_BLOCK_SIZE(r) FIELD_GET(RMI_ADDR_RANGE_SIZE_MASK, r)
>> #define RMI_ADDR_RANGE_BLOCK_COUNT(r) FIELD_GET(RMI_ADDR_RANGE_COUNT_MASK, r)
>> #define RMI_ADDR_RANGE_ADDR(r) FIELD_GET(RMI_ADDR_RANGE_ADDR_MASK, r)
>> #define RMI_ADDR_RANGE_STATE(r) FIELD_GET(RMI_ADDR_RANGE_STATE_MASK, r)
> 
> Ack
> 
>>
>>> +enum rmi_ripas {
>>> +    RMI_EMPTY = 0,
>>> +    RMI_RAM = 1,
>>> +    RMI_DESTROYED = 2,
>>> +    RMI_DEV = 3,
>>> +};
> 
>>> +#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_4KB    BIT(0)
>>> +#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_16KB    BIT(1)
>>> +#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_64KB    BIT(2)
>>> +#define RMI_FEATURE_REGISTER_1_HASH_SHA_256    BIT(3)
>>> +#define RMI_FEATURE_REGISTER_1_HASH_SHA_384    BIT(4)
>>> +#define RMI_FEATURE_REGISTER_1_HASH_SHA_512    BIT(5)
>>> +#define RMI_FEATURE_REGISTER_1_MAX_RECS_ORDER    GENMASK(9, 6)
>>> +#define RMI_FEATURE_REGISTER_1_L0GPTSZ        GENMASK(13, 10)
>>> +#define RMI_FEATURE_REGISTER_1_PPS        GENMASK(16, 14)
>>> +
>>> +#define RMI_FEATURE_REGISTER_2_DA        BIT(0)
>>> +#define RMI_FEATURE_REGISTER_2_DA_COH        BIT(1)
>>> +#define RMI_FEATURE_REGISTER_2_VSMMU        BIT(2)
>>> +#define RMI_FEATURE_REGISTER_2_ATS        BIT(3)
>>> +#define RMI_FEATURE_REGISTER_2_PDEV_MAX_VDEVS_ORDER    GENMASK(7, 4)
>>> +#define RMI_FEATURE_REGISTER_2_VDEV_KROU    BIT(8)
>>> +#define RMI_FEATURE_REGISTER_2_NON_TEE_STREAM    BIT(9)
>>> +#define RMI_FEATURE_REGISTER_2_REALM_MAX_VDEVS_ORDER    GENMASK(14, 10)
>>> +
>>> +#define RMI_FEATURE_REGISTER_3_MAX_NUM_AUX_PLANES    GENMASK(3, 0)
>>> +#define RMI_FEATURE_REGISTER_3_RTT_PLANE        GENMASK(5, 4)
>>> +#define RMI_FEATURE_REGISTER_3_RTT_S2AP_INDIRECT    BIT(6)
>>> +
>>> +#define RMI_FEATURE_REGISTER_4_MEC_COUNT        GENMASK(63, 0)
>>> +
>>
>> We would reorder those feature register definitions from MSB ro LSB :-)
> 
> Ack
> 
> Thanks for your review.
> 
> Cheers
> Suzuki
> 

Thanks,
Gavin


  reply	other threads:[~2026-09-08 22:41 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 [this message]
2026-09-09  8:39         ` Suzuki K Poulose
2026-09-10  9:47           ` Gavin Shan
2026-09-10  9:54             ` Suzuki K Poulose
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=52e58930-8fa4-4c75-981c-25be42d83f2d@redhat.com \
    --to=gshan@redhat.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=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=suzuki.poulose@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.