Re: [PATCH v20 6/9] firmware: arm_rmm: Ensure the RMM has GPT entries for memory

[Sudeep Holla]

On Tue, Sep 29, 2026 at 11:16:20PM +0100, Suzuki K Poulose wrote:
> From: Steven Price <steven.price@xxxxxxx>
> 
> The RMM maintains the state of all the granules in the system to make
> sure that the host is abiding by the rules. This state can be maintained
> at different granularity, per page (TRACKING_FINE) or per region
> (TRACKING_COARSE or TRACKING_INTERMEDIATE). The region size depends on the
> underlying "RMI_GRANULE_SIZE". For a "coarse"/"intermediate" region,
> all pages in the region must be of the same state, this implies we need to
> have "fine" tracking for DRAM, so that we can delegate individual pages.
> 
> For now we only support a statically carved out memory for tracking
> granules for the "fine" regions. This can be extended in the future to
> allow modifying the tracking granularity and remove the need for a
> static allocation by the firmware.
> 
> Similarly, the firmware may create L0 GPT entries describing the total
> address space. But if we change the "PAS" (Physical Address Space) of a
> granule, then the firmware may need to create L1 tables to track the PAS
> at a finer granularity. Linux therefore checks if the platform firmware
> manages the PAR region. i.e., the firmware is in charge of managing the
> L1 GPTs (creation and the required memory for the GPT tables - via static
> carveouts) without host intervention. Support for dynamic GPT creation by
> the host will be added later.
> 
> If the firmware requires us to manage the tracking or GPT memory,
> deactivate the RMM and reclaim any memory donated at RMM activation.
> 
> Apply the same checks when hotplugged memory is brought online.
> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx>
> Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
> Tested-by: Gavin Shan <gshan@xxxxxxxxxx>
> Signed-off-by: Steven Price <steven.price@xxxxxxx>
> Co-developed-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
> ---
>  Changes since v19:
>    * Wrap comments to 80spaces.
>    * Add a comment on ALIGN_DOWN the end of memory range.
>    * Add is_rmm_active() to indicate if the RMM is active
>    * Switch errors to -ENODEV from -ENOMEM when RMM doesn't manage the region
>    * Print error messages when RMI_GPT_INFO/RMI_GRANULE_TRACKIN_GET fails
>  Changes since v18:
>    * Avoid mixing gotos with __free cleanups for arm64_init_rmi()
>    * Handle buggy RMM to make forward progress for RMI_GPT_INFO and
>      RMI_GRANULE_TRACKING_GET
>    * Make sure the memory ranges are not inverted and reject such ranges.
>    * Move granule_tracking_get/gpt_info wrappers closer to the callers
>      Drop "inline", let the compiler do its job
>  Changes since v17:
>    * Move wrappers that may not be used elsewhere, out of arm-rmi-cmds.h
>  Changes since v16:
>    * Check fine tracking and create L1 GPTs for hotplug-added memory.
>    * Clarify the L1 GPT setup and move the explanatory comment.
>    * Switch to using RMI_GPT_INFO command for checking the GPTs.
>    * Deactivate the RMM and reclaim the memory if we can't proceed.
>  Changes since v15:
>    * Skip firmware-reserved NOMAP memory in rmi_init_metadata()
>    * Handle negative error codes from wrappers.
>  Changes since v14:
>    * Move the implementation into drivers/firmware/arm_rmm.
>  Changes since v13:
>    * Moved out of KVM
> ---
>  drivers/firmware/arm_rmm/rmi.c | 247 ++++++++++++++++++++++++++++++++-
>  include/linux/arm-rmi-cmds.h   |  18 +++
>  2 files changed, 264 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_rmm/rmi.c b/drivers/firmware/arm_rmm/rmi.c
> index d982cf158f8da..d4d098448e46e 100644
> --- a/drivers/firmware/arm_rmm/rmi.c
> +++ b/drivers/firmware/arm_rmm/rmi.c

[...]

> +static int rmi_verify_gpt_firmware_managed(phys_addr_t start, phys_addr_t end)
> +{
> +	unsigned long l0gpt_sz;
> +	unsigned long next, par_state;
> +
> +	l0gpt_sz = 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
> +					  rmi_feat_reg(1)));
> +	start = ALIGN_DOWN(start, l0gpt_sz);
> +	end = ALIGN(end, l0gpt_sz);
> +

Is it guaranteed that end with not be = PASZ ? The spec says RMI_GPT_INFO
will return RMI_GPT_INFO when top >= pasz. Unlike start, end for good
reason is aligned up(ceil) instead of aligned down, but that also means
end will become PASZ when we reach end of memory, no ?

Sorry if I am missing something, trying to understand bits and piece of
RME still, just getting started.

> +	while (start < end) {
> +		long ret = rmi_gpt_info(start, end, &next, &par_state);
> +
> +		if (ret != RMI_SUCCESS) {
> +			pr_err("RMI_GPT_INFO failed for %llx-%llx: (%ld)\n",
> +				start, end, ret);
> +			return -ENXIO;
> +		}
> +
> +		if (WARN_ON(next <= start))
> +			return -ENXIO;
> +
> +		if (par_state != RMI_GPT_PAR_PLAT) {
> +			pr_err("GPT for the region is not managed by firmware %llx-%lx\n",
> +				start, next);
> +			return -ENODEV;
> +		}
> +		start = next;
> +	}
> +
> +	return 0;
> +}
> +

-- 
Regards,
Sudeep