All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvmarm@lists.linux.dev, Marc Zyngier <maz@kernel.org>,
	kvm@vger.kernel.org, Oliver Upton <oupton@kernel.org>
Subject: Re: [PATCH v17 3/7] firmware: arm_rmm: Configure the RMM with the host's page size
Date: Mon, 7 Sep 2026 13:02:06 +0100	[thread overview]
Message-ID: <bade4920-2db1-4a8a-99d1-ca2694647ec8@arm.com> (raw)
In-Reply-To: <20260907101446.1DA321F00A3A@smtp.kernel.org>

On 07/09/2026 11:14, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The SMC call leaves parameters X2-X7 uninitialized, violating the RMM's RES0 requirement.
> - [High] The `struct rmm_config` fields are populated using native endianness, which breaks on Big Endian kernels.
> --
> 
> commit 1741e17729c2ff5e23bc8bfb00cc50a61f38ebb7
> Author: Steven Price <steven.price@arm.com>
> firmware: arm_rmm: Configure the RMM with the host's page size
> 
> This commit adds support to configure the RMM's granule size to match the
> host's page size during kernel initialization. It reads the feature
> registers to ensure the requested page size is supported and sends the
> configuration to the RMM via an SMC call.
> 
>> 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) {
> [ ... ]
>> +
>> +	config = (struct rmm_config *)get_zeroed_page(GFP_KERNEL);
>> +	if (!config)
>> +		return -ENOMEM;
>> +
>> +	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;
> 
> [Severity: High]
> Does this code handle endianness correctly?
> 
> The struct rmm_config fields are populated using native u64 assignments.
> On an ARM64 kernel compiled with CONFIG_CPU_BIG_ENDIAN=y, this writes
> big-endian bytes into the shared memory. The RMM, which runs in little-endian
> at EL2, will misinterpret these fields.
> 
> Will this cause the RMM firmware to read invalid configuration values (like a
> byte-swapped granule size) and fail to configure, breaking RMI support on Big
> Endian systems?
> 

We don't plan to support RMM for Big Endian Linux. I have now made the 
ARCH_SUPPORTS_RMM to depend on !CPU_BIG_ENDIAN

>> +
>> +	ret = rmi_rmm_config_set(virt_to_phys(config));
>> +	if (ret) {
>> +		pr_err("RMM config set failed\n");
>> +		ret = -EINVAL;
>> +	}
>> +
>> +	free_page((unsigned long)config);
>> +	return ret;
>> +}
> [ ... ]
>> 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);
> 
> [Severity: High]
> Does this SMC call leave parameters x2 through x7 uninitialized?
> 
> The arm_smccc_1_1_invoke macro only generates inline assembly constraints
> for the explicitly provided arguments. It does not zero-pad omitted arguments,
> leaving registers x2 through x7 with whatever was previously in them.
> 
> Since the RMM firmware expects unused SMC parameters to be zero (RES0),
> could passing uninitialized values cause the RMM to reject the command
> with an INVALID_PARAMETER error and sporadically break RMM initialization?

Correct, I have now moved all RMI calls to smccc_1_2, making sure that
all the undefined arguments are initialised to 0.

Cheers
Suzuki


> 
>> +
>> +	return res.a0;
>> +}
> 


  reply	other threads:[~2026-09-07 12:02 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 [this message]
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=bade4920-2db1-4a8a-99d1-ca2694647ec8@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.