From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Steven Price <steven.price@arm.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
James Morse <james.morse@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Fuad Tabba <tabba@google.com>,
linux-coco@lists.linux.dev,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
Gavin Shan <gshan@redhat.com>,
Shanker Donthineni <sdonthineni@nvidia.com>,
Alper Gun <alpergun@google.com>,
"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
Emi Kisanuki <fj0570is@fujitsu.com>,
Vishal Annapurve <vannapurve@google.com>
Subject: Re: [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory
Date: Thu, 19 Mar 2026 10:31:28 +0000 [thread overview]
Message-ID: <b83d601c-c4a0-4e6b-aae0-e49f02e67e30@arm.com> (raw)
In-Reply-To: <20260318155413.793430-11-steven.price@arm.com>
Hi Steven
On 18/03/2026 15:53, Steven Price wrote:
> The RMM may not be tracking all the memory of the system at boot. Create
Looks good to me. Please find some suggestions below.
May be add a bit more context here :
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 (COARSE),
where the "region size" depends on the underlying "RMI_GRANULE_SIZE".
The state of the "tracked area" must be the same. This implies, we may
need to have "FINE" tracking for DRAM, so that we can start delegating
PAGEs. For now, we only support RMM with statically carved out memory
for tracking FINE granularity for the tracking regions. We will extend
the support for modifying the TRACKING region in the future.
Similarly, the firmware may create L0 GPT entries describing the total
address space (think of this as Block mappings in the page tables). But
if we change the "PAS" of a granule in the block mapping, we may need
to create L1 tables to track the PAS at the finer granularity. For now
we only support a system where the L1 GPTs are created at boot time
and dynamic GPT support will be added later.
> the necessary tracking state and GPTs within the RMM so that all boot
> memory can be delegated to the RMM as needed during runtime.
>
> Note: support is currently missing for SROs which means that if the RMM
> needs memory donating this will fail (and render CCA unusable in Linux).
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> New patch for v13
> ---
> arch/arm64/kvm/rmi.c | 89 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
> index 9590dff9a2c1..80aedc85e94a 100644
> --- a/arch/arm64/kvm/rmi.c
> +++ b/arch/arm64/kvm/rmi.c
> @@ -4,6 +4,7 @@
> */
>
> #include <linux/kvm_host.h>
> +#include <linux/memblock.h>
>
> #include <asm/kvm_pgtable.h>
> #include <asm/rmi_cmds.h>
> @@ -56,6 +57,18 @@ static int rmi_check_version(void)
> return 0;
> }
>
> +/*
> + * These are the 'default' sizes when passing 0 as the tracking_region_size.
> + * TODO: Support other granule sizes
> + */
> +#ifdef CONFIG_PAGE_SIZE_4KB
> +#define RMM_GRANULE_TRACKING_SIZE SZ_1G
> +#elif defined(CONFIG_PAGE_SIZE_16KB)
> +#define RMM_GRANULE_TRACKING_SIZE SZ_32M
> +#elif defined(CONFIG_PAGE_SIZE_64KB)
> +#define RMM_GRANULE_TRACKING_SIZE SZ_512M
> +#endif
> +
Probably this should be made a Kconfig option, like the VA_BITS we have
today for each page size.
> static int rmi_configure(void)
> {
> struct rmm_config *config __free(free_page) = NULL;
> @@ -95,6 +108,80 @@ static int rmi_configure(void)
> return 0;
> }
>
> +static int rmi_verify_memory_tracking(phys_addr_t start, phys_addr_t end)
Could we add a comment what we are trying to do here ?
/*
* Make sure the area is tracked by RMM at FINE granularity.
* We do not support changing the TRACKING yet. This will
* be added in the future.
*/
> +{
> + start = ALIGN_DOWN(start, RMM_GRANULE_TRACKING_SIZE);
> + end = ALIGN(end, RMM_GRANULE_TRACKING_SIZE);
> +
> + while (start < end) {
> + unsigned long ret, category, state;
> +
> + ret = rmi_granule_tracking_get(start, &category, &state);
> + if (ret != RMI_SUCCESS ||
> + state != RMI_TRACKING_FINE ||
> + category != RMI_MEM_CATEGORY_CONVENTIONAL) {
> + /* TODO: Set granule tracking in this case */
> + kvm_err("Granule tracking for region isn't fine/conventional: %llx",
> + start);
> + return -ENODEV;
> + }
> + start += RMM_GRANULE_TRACKING_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +static unsigned long rmi_l0gpt_size(void)
> +{
> + return 1UL << (30 + FIELD_GET(RMI_FEATURE_REGISTER_1_L0GPTSZ,
> + rmm_feat_reg1));
> +}
> +
> +static int rmi_create_gpts(phys_addr_t start, phys_addr_t end)
> +{
> + unsigned long l0gpt_sz = rmi_l0gpt_size();
> +
> + start = ALIGN_DOWN(start, l0gpt_sz);
> + end = ALIGN(end, l0gpt_sz);
> +
> + while (start < end) {
> + int ret = rmi_gpt_l1_create(start);
How about adding a comment here explaining why we look for RMI_ERROR_GPT ?
>
/*
* Make sure the L1 GPT tables are created for the region.
* RMI_ERROR_GPT indicates the L1 table exists.
*/
+
> + if (ret && ret != RMI_ERROR_GPT) {
> + /*
> + * FIXME: Handle SRO so that memory can be donated for
> + * the tables.
> + */
> + kvm_err("GPT Level1 table missing for %llx\n", start);
> + return -ENOMEM;
> + }
> + start += l0gpt_sz;
> + }
> +
> + return 0;
> +}
> +
> +static int rmi_init_metadata(void)
> +{
> + phys_addr_t start, end;
> + const struct memblock_region *r;
> +
> + for_each_mem_region(r) {
> + int ret;
> +
> + start = memblock_region_memory_base_pfn(r) << PAGE_SHIFT;
> + end = memblock_region_memory_end_pfn(r) << PAGE_SHIFT;
> + ret = rmi_verify_memory_tracking(start, end);
> + if (ret)
> + return ret;
> + ret = rmi_create_gpts(start, end);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int rmm_check_features(void)
> {
> if (kvm_lpa2_is_enabled() && !rmi_has_feature(RMI_FEATURE_REGISTER_0_LPA2)) {
> @@ -120,6 +207,8 @@ void kvm_init_rmi(void)
> return;
> if (rmi_configure())
> return;
> + if (rmi_init_metadata())
> + return;
>
> /* Future patch will enable static branch kvm_rmi_is_available */
> }
next prev parent reply other threads:[~2026-03-19 10:32 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 15:53 [PATCH v13 00/48] arm64: Support for Arm CCA in KVM Steven Price
2026-03-18 15:53 ` [PATCH v13 01/48] kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h Steven Price
2026-03-18 15:53 ` [PATCH v13 02/48] kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Steven Price
2026-03-18 15:53 ` [PATCH v13 03/48] arm64: RME: Handle Granule Protection Faults (GPFs) Steven Price
2026-03-18 15:53 ` [PATCH v13 04/48] arm64: RMI: Add SMC definitions for calling the RMM Steven Price
2026-03-18 16:07 ` Joey Gouly
2026-03-18 17:07 ` Steven Price
2026-03-18 15:53 ` [PATCH v13 05/48] arm64: RMI: Temporarily add SMCs from RMM v1.0 spec Steven Price
2026-03-21 13:21 ` Marc Zyngier
2026-03-23 10:30 ` Suzuki K Poulose
2026-03-18 15:53 ` [PATCH v13 06/48] arm64: RMI: Add wrappers for RMI calls Steven Price
2026-03-18 15:53 ` [PATCH v13 07/48] arm64: RMI: Check for RMI support at KVM init Steven Price
2026-03-19 10:38 ` Suzuki K Poulose
2026-03-19 12:47 ` Steven Price
2026-03-19 16:17 ` Wei-Lin Chang
2026-03-19 16:42 ` Steven Price
2026-03-19 18:05 ` Wei-Lin Chang
2026-03-20 16:01 ` Steven Price
2026-03-18 15:53 ` [PATCH v13 08/48] arm64: RMI: Configure the RMM with the host's page size Steven Price
2026-03-18 15:53 ` [PATCH v13 09/48] arm64: RMI: Check for LPA2 support Steven Price
2026-03-18 15:53 ` [PATCH v13 10/48] arm64: RMI: Ensure that the RMM has GPT entries for memory Steven Price
2026-03-19 10:31 ` Suzuki K Poulose [this message]
2026-03-19 15:20 ` Steven Price
2026-03-19 10:41 ` Suzuki K Poulose
2026-03-18 15:53 ` [PATCH v13 11/48] arm64: RMI: Define the user ABI Steven Price
2026-03-18 15:53 ` [PATCH v13 12/48] arm64: RMI: Basic infrastructure for creating a realm Steven Price
2026-03-19 16:11 ` Wei-Lin Chang
2026-03-19 16:24 ` Steven Price
2026-03-19 17:17 ` Wei-Lin Chang
2026-03-20 16:07 ` Steven Price
2026-03-21 16:34 ` Wei-Lin Chang
2026-03-18 15:53 ` [PATCH v13 13/48] kvm: arm64: Don't expose unsupported capabilities for realm guests Steven Price
2026-03-19 14:09 ` Suzuki K Poulose
2026-03-19 15:25 ` Steven Price
2026-03-18 15:53 ` [PATCH v13 14/48] KVM: arm64: Allow passing machine type in KVM creation Steven Price
2026-03-18 15:53 ` [PATCH v13 15/48] arm64: RMI: RTT tear down Steven Price
2026-03-19 17:35 ` Wei-Lin Chang
2026-03-20 16:12 ` Steven Price
2026-03-21 13:04 ` Wei-Lin Chang
2026-03-20 10:37 ` Suzuki K Poulose
2026-03-20 16:14 ` Steven Price
2026-03-18 15:53 ` [PATCH v13 16/48] arm64: RMI: Activate realm on first VCPU run Steven Price
2026-03-18 15:53 ` [PATCH v13 17/48] arm64: RMI: Allocate/free RECs to match vCPUs Steven Price
2026-03-19 18:10 ` Wei-Lin Chang
2026-03-20 16:26 ` Steven Price
2026-03-23 11:56 ` Suzuki K Poulose
2026-03-18 15:53 ` [PATCH v13 18/48] arm64: RMI: Support for the VGIC in realms Steven Price
2026-03-18 15:53 ` [PATCH v13 19/48] KVM: arm64: Support timers in realm RECs Steven Price
2026-03-18 15:53 ` [PATCH v13 20/48] arm64: RMI: Handle realm enter/exit Steven Price
2026-03-20 14:08 ` Suzuki K Poulose
2026-03-20 16:32 ` Steven Price
2026-03-23 10:03 ` Suzuki K Poulose
2026-03-18 15:53 ` [PATCH v13 21/48] arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE Steven Price
2026-03-20 11:15 ` Suzuki K Poulose
2026-03-18 15:53 ` [PATCH v13 22/48] KVM: arm64: Handle realm MMIO emulation Steven Price
2026-03-18 15:53 ` [PATCH v13 23/48] KVM: arm64: Expose support for private memory Steven Price
2026-03-19 19:01 ` Wei-Lin Chang
2026-03-20 16:39 ` Steven Price
2026-03-18 15:53 ` [PATCH v13 24/48] arm64: RMI: Allow populating initial contents Steven Price
2026-03-23 11:32 ` Suzuki K Poulose
2026-03-18 15:53 ` [PATCH v13 25/48] arm64: RMI: Set RIPAS of initial memslots Steven Price
2026-03-18 15:53 ` [PATCH v13 26/48] arm64: RMI: Create the realm descriptor Steven Price
2026-03-19 18:25 ` Wei-Lin Chang
2026-03-20 16:41 ` Steven Price
2026-03-21 16:20 ` Wei-Lin Chang
2026-03-18 15:53 ` [PATCH v13 27/48] arm64: RMI: Runtime faulting of memory Steven Price
2026-03-19 18:41 ` Wei-Lin Chang
2026-03-20 16:44 ` Steven Price
2026-03-18 15:53 ` [PATCH v13 28/48] KVM: arm64: Handle realm VCPU load Steven Price
2026-03-18 15:53 ` [PATCH v13 29/48] KVM: arm64: Validate register access for a Realm VM Steven Price
2026-03-18 15:53 ` [PATCH v13 30/48] KVM: arm64: Handle Realm PSCI requests Steven Price
2026-03-18 15:53 ` [PATCH v13 31/48] KVM: arm64: WARN on injected undef exceptions Steven Price
2026-03-18 15:53 ` [PATCH v13 32/48] arm64: Don't expose stolen time for realm guests Steven Price
2026-03-18 15:53 ` [PATCH v13 33/48] arm64: RMI: allow userspace to inject aborts Steven Price
2026-03-18 15:53 ` [PATCH v13 34/48] arm64: RMI: support RSI_HOST_CALL Steven Price
2026-03-18 15:53 ` [PATCH v13 35/48] arm64: RMI: Allow checking SVE on VM instance Steven Price
2026-03-18 15:54 ` [PATCH v13 36/48] arm64: RMI: Always use 4k pages for realms Steven Price
2026-03-19 10:24 ` Joey Gouly
2026-03-19 16:02 ` Steven Price
2026-03-18 15:54 ` [PATCH v13 37/48] arm64: RMI: Prevent Device mappings for Realms Steven Price
2026-03-19 10:27 ` Joey Gouly
2026-03-19 18:46 ` Wei-Lin Chang
2026-03-20 16:45 ` Steven Price
2026-03-21 16:23 ` Wei-Lin Chang
2026-03-18 15:54 ` [PATCH v13 38/48] arm64: RMI: Enable PMU support with a realm guest Steven Price
2026-03-18 15:54 ` [PATCH v13 39/48] arm64: RMI: Propagate number of breakpoints and watchpoints to userspace Steven Price
2026-03-19 18:50 ` Wei-Lin Chang
2026-03-20 16:45 ` Steven Price
2026-03-18 15:54 ` [PATCH v13 40/48] arm64: RMI: Set breakpoint parameters through SET_ONE_REG Steven Price
2026-03-18 15:54 ` [PATCH v13 41/48] arm64: RMI: Initialize PMCR.N with number counter supported by RMM Steven Price
2026-03-18 15:54 ` [PATCH v13 42/48] arm64: RMI: Propagate max SVE vector length from RMM Steven Price
2026-03-18 15:54 ` [PATCH v13 43/48] arm64: RMI: Configure max SVE vector length for a Realm Steven Price
2026-03-18 15:54 ` [PATCH v13 44/48] arm64: RMI: Provide register list for unfinalized RMI RECs Steven Price
2026-03-18 15:54 ` [PATCH v13 45/48] arm64: RMI: Provide accurate register list Steven Price
2026-03-19 18:53 ` Wei-Lin Chang
2026-03-20 16:45 ` Steven Price
2026-03-18 15:54 ` [PATCH v13 46/48] KVM: arm64: Expose KVM_ARM_VCPU_REC to user space Steven Price
2026-03-19 17:36 ` Suzuki K Poulose
2026-03-18 15:54 ` [PATCH v13 47/48] arm64: RMI: Enable realms to be created Steven Price
2026-03-18 15:54 ` [PATCH v13 48/48] [WIP] arm64: RMI: Add support for SRO Steven Price
2026-03-18 16:53 ` [PATCH v13 00/48] arm64: Support for Arm CCA in KVM Steven Price
2026-03-19 23:02 ` Mathieu Poirier
2026-03-20 16:45 ` Steven Price
2026-03-20 19:15 ` Mathieu Poirier
2026-03-25 6:37 ` Gavin Shan
2026-03-25 10:16 ` Suzuki K Poulose
2026-03-25 11:32 ` Suzuki K Poulose
2026-03-26 0:48 ` Gavin Shan
2026-03-26 11:22 ` Suzuki K Poulose
2026-03-25 4:07 ` Gavin Shan
2026-03-25 10:19 ` Suzuki K Poulose
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=b83d601c-c4a0-4e6b-aae0-e49f02e67e30@arm.com \
--to=suzuki.poulose@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=alpergun@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=fj0570is@fujitsu.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.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=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=sdonthineni@nvidia.com \
--cc=steven.price@arm.com \
--cc=tabba@google.com \
--cc=vannapurve@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox