From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, maz@kernel.org,
will@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com,
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,
sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com
Subject: Re: [PATCH v19 4/7] firmware: arm_rmm: Add support for SRO
Date: Fri, 25 Sep 2026 16:11:29 +0100 [thread overview]
Message-ID: <0c959443-6d4f-4dba-957c-420cb128b7cc@arm.com> (raw)
In-Reply-To: <arZgDmHV8uK1kv8R@arm.com>
On 25/09/2026 12:50, Catalin Marinas wrote:
> On Thu, Sep 24, 2026 at 02:51:58PM +0100, Suzuki K Poulose wrote:
>> +static int rmi_sro_donate_contig(struct rmi_sro_state *sro,
>> + unsigned long sro_handle,
>> + unsigned long donatereq,
>> + struct arm_smccc_1_2_regs *out_regs,
>> + gfp_t gfp)
>> +{
>> + unsigned long block_size_fld = RMI_DONATE_BLOCK_SIZE(donatereq);
>> + unsigned long block_size = rmi_addr_block_size_to_bytes(block_size_fld);
>> + unsigned long count = RMI_DONATE_COUNT(donatereq);
>> + unsigned long state = RMI_DONATE_STATE(donatereq);
>> + unsigned long size = block_size * count;
>> + unsigned long addr_range;
>> + unsigned long donated_granules;
>> + unsigned long donated_size;
>> + int ret;
>> + void *virt;
>> + phys_addr_t phys;
>> +
>> + /*
>> + * The RMM specification requires contiguous allocations are always a
>> + * power of 2
>> + */
>> + if (WARN_ON_ONCE(!is_power_of_2(size)))
>> + return -EINVAL;
>> +
>> + /* Reuse the cached address range if we have one */
>> + for (int i = 0; i < sro->addr_count; i++) {
>> + unsigned long entry = sro->addr_list[i];
>> +
>> + if (RMI_ADDR_RANGE_BLOCK_SIZE(entry) == block_size_fld &&
>> + RMI_ADDR_RANGE_COUNT(entry) == count &&
>> + RMI_ADDR_RANGE_STATE(entry) == state &&
>> + IS_ALIGNED(RMI_ADDR_RANGE_ADDR(entry), size)) {
>> + sro->addr_count--;
>> + swap(sro->addr_list[sro->addr_count],
>> + sro->addr_list[i]);
>> +
>> + goto mem_donate;
>> + }
>> + }
>> +
>> + ret = rmi_sro_ensure_capacity(sro, 1);
>> + if (ret)
>> + return ret;
>> +
>> + virt = alloc_pages_exact(size, gfp);
>> + if (!virt)
>> + return -ENOMEM;
>> + phys = virt_to_phys(virt);
>> +
>> + if (state == RMI_OP_MEM_DELEGATED) {
>> + phys_addr_t delegated_phys;
>> +
>> + if (rmi_delegate_range(phys, size, &delegated_phys)) {
>> + if (!rmi_undelegate_range(phys, delegated_phys - phys))
>> + free_pages_exact(virt, size);
>> + return -ENXIO;
>> + }
>> + }
>> +
>> + addr_range = phys & RMI_ADDR_RANGE_ADDR_MASK;
>> + FIELD_MODIFY(RMI_ADDR_RANGE_BLOCK_SIZE_MASK, &addr_range, block_size_fld);
>> + FIELD_MODIFY(RMI_ADDR_RANGE_COUNT_MASK, &addr_range, count);
>
> Courtesy of an LLM - if we get a contiguous/4K pages request for 4MB
> (1024 pages), the above 10-bit field becomes 0. Should we reject the
> request or the updated spec will guarantee this won't happen?
The spec is being updated to clamp the "maximum" count to match the
granule size. (Also called out in the Cover letter as "Known Issues")
This will be available with beta4 version of the spec.
>
> Somewhat related, with RMI_BLOCK_L2 or higher and appropriate count we
> can easily go over the MAX_PAGE_ORDER allocation and fail alloc_pages()
> (the contig case). IIUC, the kernel can reject the donation but current
> TF-RMM does not report RMI_OP_CAN_CANCEL (R_SZVNK says it can be
> cancelled). It gets complicated if we want to support large contiguous
Ack, I will get this fixed in the TF-RMM.
> allocations here (e.g. alloc_contig_pages() can sleep). I'd rather just
> cancel the request, not support such large sizes.
>
> [...]
>
>> +static int rmi_sro_donate_noncontig(struct rmi_sro_state *sro,
>> + unsigned long sro_handle,
>> + unsigned long donatereq,
>> + struct arm_smccc_1_2_regs *out_regs,
>> + gfp_t gfp)
>> +{
>> + unsigned long block_size_fld = RMI_DONATE_BLOCK_SIZE(donatereq);
>> + unsigned long block_size = rmi_addr_block_size_to_bytes(block_size_fld);
>> + unsigned long count = RMI_DONATE_COUNT(donatereq);
>> + unsigned long state = RMI_DONATE_STATE(donatereq);
>> + unsigned long found = 0;
>> + unsigned long donated_granules;
>> + unsigned long granules_per_block = block_size >> PAGE_SHIFT;
>> + unsigned long consumed_blocks;
>> + int addr_list_start = sro->addr_count;
>> + int ret, i;
>
> [...]
>
>> + for (int i = 0, src = addr_list_start + consumed_blocks;
>
> Nit: we have 'int ret, i' earlier already, so you can drop the 'int'
> here.
>
> [...]
>
>> +/*
>> + * rmi_sro_execute: Execute an RMI command that is Stateful but not memory
>> + * tranfserring. Takes regs, filled with the FIDs and the arguments in place.
>> + *
>> + * Returns :
>> + * -ECANCELLED - If the operation had to be aborted and SRO was cancellable.
>
> Nit: -ECANCELED.
>
Ack
>> + * Otherwise, returns the result of the RMI command.
>> + */
>> +long rmi_sro_execute(struct arm_smccc_1_2_regs *regs)
>> +{
>> + bool cancelled = false;
>> + unsigned long sro_handle = regs->a1;
>> +
>> + rmi_smccc_invoke(regs);
>> +
>> + sro_handle = regs->a1;
>
> Nit: drop the first initialisation maybe?
Of course, I will do that. Thanks for spotting.
Suzuki
>
next prev parent reply other threads:[~2026-09-25 15:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 13:51 [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 1/7] firmware: arm_rmm: Add SMC definitions for calling the RMM Suzuki K Poulose
2026-09-24 16:57 ` Jonathan Cameron
2026-09-24 22:15 ` Suzuki K Poulose
2026-09-24 17:05 ` Ackerley Tng
2026-09-24 22:49 ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 2/7] firmware: arm_rmm: Check for RMI support at init Suzuki K Poulose
2026-09-24 16:58 ` Jonathan Cameron
2026-09-25 0:00 ` Gavin Shan
2026-09-25 8:51 ` Suzuki K Poulose
2026-09-25 5:43 ` Gavin Shan
2026-09-25 8:50 ` Suzuki K Poulose
2026-09-25 10:42 ` Catalin Marinas
2026-09-25 15:23 ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 3/7] firmware: arm_rmm: Configure the RMM with the host's page size Suzuki K Poulose
2026-09-24 17:03 ` Jonathan Cameron
[not found] ` <d4b768e5-c942-43cf-aea2-c266a8bab353@oss.qualcomm.com>
2026-09-25 14:56 ` Suzuki K Poulose
2026-09-25 0:03 ` Gavin Shan
2026-09-24 13:51 ` [PATCH v19 4/7] firmware: arm_rmm: Add support for SRO Suzuki K Poulose
2026-09-24 19:13 ` Jonathan Cameron
2026-09-24 23:10 ` Suzuki K Poulose
2026-09-25 5:24 ` Gavin Shan
2026-09-25 11:50 ` Catalin Marinas
2026-09-25 15:11 ` Suzuki K Poulose [this message]
2026-09-24 13:51 ` [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM Suzuki K Poulose
2026-09-25 12:17 ` Catalin Marinas
2026-09-25 15:02 ` Suzuki K Poulose
2026-09-25 15:34 ` Alper Gun
2026-09-25 16:42 ` Catalin Marinas
2026-09-25 17:50 ` Suzuki K Poulose
2026-09-24 13:52 ` [PATCH v19 6/7] firmware: arm_rmm: Ensure the RMM has GPT entries for memory Suzuki K Poulose
2026-09-24 21:38 ` Jonathan Cameron
2026-09-24 23:30 ` Suzuki K Poulose
2026-09-25 15:30 ` Jonathan Cameron
2026-09-25 0:07 ` Gavin Shan
2026-09-24 13:52 ` [PATCH v19 7/7] firmware: arm_rmm: Add wrappers for Realm related RMI commands Suzuki K Poulose
2026-09-25 11:56 ` Catalin Marinas
2026-09-25 6:29 ` [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Gavin Shan
2026-09-25 9:03 ` 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=0c959443-6d4f-4dba-957c-420cb128b7cc@arm.com \
--to=suzuki.poulose@arm.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=gshan@redhat.com \
--cc=joey.gouly@arm.com \
--cc=jonathan.cameron@oss.qualcomm.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=sudeep.holla@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®