From: Gavin Shan <gshan@redhat.com>
To: Kohei Enju <enju.kohei@fujitsu.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev, 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
Subject: Re: [PATCH v17 3/7] firmware: arm_rmm: Configure the RMM with the host's page size
Date: Tue, 8 Sep 2026 20:59:45 +1000 [thread overview]
Message-ID: <9706a0b9-b686-4502-bfae-08aabe05fb84@redhat.com> (raw)
In-Reply-To: <ap--9pJdD_Y_j1aY@FCCLS0092175.localdomain>
Hi Kohei,
On 9/8/26 6:00 PM, Kohei Enju wrote:
> Hi Gavin,
>
> On 09/08 17:04, Gavin Shan wrote:
>> Hi Suzuki,
>>
>> On 9/7/26 7:59 PM, Suzuki K Poulose wrote:
>>> From: Steven Price <steven.price@arm.com>
>>>
>>> RMM v2.0 brings the ability to set the RMM's granule size. Check the
>>> feature registers and configure the RMM so that it matches the host's
>>> page size. This means that operations can be done with a granularity
>>> equal to PAGE_SIZE.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> ---
>>> Changes since v15:
>>> * Actually check the feature register for the host's page-size support.
>>> Changes since v14:
>>> * Move the implementation into drivers/firmware/arm_rmm.
>>> Changes since v13:
>>> * Moved out of KVM.
>>> ---
>>> drivers/firmware/arm_rmm/rmi.c | 58 ++++++++++++++++++++++++++++++++++
>>> include/linux/arm-rmi-cmds.h | 17 ++++++++++
>>> 2 files changed, 75 insertions(+)
>>>
>>> diff --git a/drivers/firmware/arm_rmm/rmi.c b/drivers/firmware/arm_rmm/rmi.c
>>> index 008a783407b4e..76f91c145e1fd 100644
>>> --- a/drivers/firmware/arm_rmm/rmi.c
>>> +++ b/drivers/firmware/arm_rmm/rmi.c
>>> @@ -77,6 +77,60 @@ static int rmi_read_features(void)
>>> return 0;
>>> }
>>> +static int rmi_configure(void)
>>> +{
>>> + unsigned long granule_feature;
>>> + unsigned long granule_size;
>>> + int ret = 0;
>>> + struct rmm_config *config;
>>> +
>>> + switch (PAGE_SIZE) {
>>> + case SZ_4K:
>>> + granule_size = RMI_GRANULE_SIZE_4KB;
>>> + granule_feature = RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_4KB;
>>> + break;
>>> + case SZ_16K:
>>> + granule_size = RMI_GRANULE_SIZE_16KB;
>>> + granule_feature = RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_16KB;
>>> + break;
>>> + case SZ_64K:
>>> + granule_size = RMI_GRANULE_SIZE_64KB;
>>> + granule_feature = RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_64KB;
>>> + break;
>>> + default:
>>> + BUILD_BUG();
>>> + }
>>> +
>>> + if (!(rmi_feat_reg(1) & granule_feature)) {
>>> + pr_err("RMM does not support %luKB granules\n",
>>> + PAGE_SIZE >> 10);
>>> + return -ENXIO;
>>> + }
>>> +
>>> + config = (struct rmm_config *)get_zeroed_page(GFP_KERNEL);
>>> + if (!config)
>>> + return -ENOMEM;
>>
>> An error message is needed here.
>>
>> if (!config) {
>> pr_err("Unable to alloc RMM config memory\n");
>> return -ENOMEM;
>> }
>
> I largely agree with your suggestions, and they look reasonable to me.
>
> However, wouldn't this be redundant? Since __GFP_NOWARN is not set, the
> page allocator would normally emit an allocation failure warning with a
> stack trace anyway.
>
> I don't have a strong preference, but as per "14) Allocating memory" in
> the coding style, I believe it would be considered unnecessary.
>
You're correct that the error message is most likely redundant here and we
needn't it. However, it's notable the allocation failure warning and stack
trace isn't 100% raised when looking at mm/page_alloc.c::warn_alloc(). At least,
it depends on !__ratelimit(&nopage_rs) even it's less likely to happen. Similarly,
there are conditions to raise a warning and stack track in case of the injected
allocation error in lib/fault-inject.c::fail_dump().
Thanks,
Gavin
> Thanks,
> Kohei
>
>>
>>> +
>>> + config->rmi_granule_size = granule_size;
>>> +
>>> + /*
>>> + * For now we set the tracking_region_size to 0 which is the only option
>>> + * for 4KB PAGE_SIZE (1GB for 4KB PAGE_SIZE, 32MB/512MB for 16KB/64KB).
>>> + * TODO: Support other tracking sizes via Kconfig option for other
>>> + * PAGE_SIZES
>>> + */
>>> + config->tracking_region_size = 0;
>>> +
>>> + ret = rmi_rmm_config_set(virt_to_phys(config));
>>> + if (ret) {
>>> + pr_err("RMM config set failed\n");
>>> + ret = -EINVAL;
>>> + }
>>
>> The error code from rmi_rmm_config_set() is indicative sometimes. Also, -ENXIO
>> would be more appropriate than -EINVAL?
>>
>> if (ret) {
>> pr_err("RMM config set failed (%d)\n", ret);
>> ret = -ENXIO;
>> }
>>
>>> +
>>> + free_page((unsigned long)config);
>>> + return ret;
>>> +}
>>> +
>>> static int __init arm64_init_rmi(void)
>>> {
>>> int ret;
>>> @@ -90,6 +144,10 @@ static int __init arm64_init_rmi(void)
>>> if (ret)
>>> return ret;
>>> + ret = rmi_configure();
>>> + if (ret)
>>> + return ret;
>>> +
>>> return 0;
>>> }
>>> diff --git a/include/linux/arm-rmi-cmds.h b/include/linux/arm-rmi-cmds.h
>>> index 2fb1f7f86d71e..9aa27697e2377 100644
>>> --- a/include/linux/arm-rmi-cmds.h
>>> +++ b/include/linux/arm-rmi-cmds.h
>>> @@ -12,6 +12,23 @@
>>> unsigned long rmi_feat_reg(unsigned long id);
>>> +/**
>>> + * rmi_rmm_config_set() - Configure the RMM
>>> + * @cfg_ptr: PA of a struct rmm_config
>>> + *
>>> + * Sets configuration options on the RMM.
>>> + *
>>> + * Return: RMI return code
>>> + */
>>> +static inline int rmi_rmm_config_set(unsigned long cfg_ptr)
>>> +{
>>> + struct arm_smccc_res res;
>>> +
>>> + arm_smccc_1_1_invoke(SMC_RMI_RMM_CONFIG_SET, cfg_ptr, &res);
>>> +
>>> + return res.a0;
>>> +}
>>> +
>>
>> rmi_rmm_config_set() is used for once by rmi.c::rmi_configure(), I would not expose
>> rmi_rmm_config_set() by combining the logic to rmi.c::rmi_configure().
>>
>>> /**
>>> * rmi_features() - Read feature register
>>> * @index: Feature register index
>>
>> Thanks,
>> Gavin
>>
>
next prev parent reply other threads:[~2026-09-08 11:00 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
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 [this message]
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=9706a0b9-b686-4502-bfae-08aabe05fb84@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.