From: Sumit Garg <sumit.garg@kernel.org>
To: Casey Connolly <casey.connolly@linaro.org>
Cc: u-boot@lists.denx.de, u-boot-qcom@groups.io,
Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,
Peng Fan <peng.fan@nxp.com>,
Marek Vasut <marek.vasut+renesas@mailbox.org>,
Alice Guo <alice.guo@nxp.com>,
Quentin Schulz <quentin.schulz@cherry.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Mattijs Korpershoek <mkorpershoek@kernel.org>,
Kuan-Wei Chiu <visitorckw@gmail.com>,
Raymond Mao <raymond.mao@riscstar.com>,
Stefan Roese <stefan.roese@mailbox.org>,
Philip Molloy <philip.molloy@analog.com>,
Jerome Forissier <jerome.forissier@arm.com>,
Marek Vasut <marek.vasut@mailbox.org>,
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Aswin Murugan <aswin.murugan@oss.qualcomm.com>,
Rasmus Villemoes <ravi@prevas.dk>,
Heiko Schocher <hs@nabladev.com>,
Michal Simek <michal.simek@amd.com>,
Sughosh Ganu <sughosh.ganu@arm.com>,
Antony Kurniawan Soemardi <linux@smankusors.com>,
Luca Weiss <luca.weiss@fairphone.com>,
Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Subject: Re: [PATCH v2 05/15] mach-snapdragon: fix reserved memory carveout
Date: Thu, 7 May 2026 13:15:32 +0530 [thread overview]
Message-ID: <afxDHAZD25moYKg8@sumit-xelite> (raw)
In-Reply-To: <9870f8f4-a719-4ea5-93b7-5442d499c19f@linaro.org>
On Tue, May 05, 2026 at 02:39:35PM +0200, Casey Connolly wrote:
>
>
> On 05/05/2026 14:25, Sumit Garg wrote:
> > On Mon, May 04, 2026 at 08:57:33PM +0200, Casey Connolly wrote:
> >> The memory carveout logic was fairly limited and had a few issues,
> >> rework it and teach it not to unmap regions that have a compatible
> >> property (since they may be used in U-Boot) or that don't have the
> >> no-map property.
> >>
> >> The carveout process adds ~100ms to the boot time depending on the
> >> platform.
> >>
> >> This prepares us for using SMEM as a source of truth and improving
> >> support for U-boot as a first stage bootloader since SMEMs memory map
> >> doesn't already carve out some regions like ABL does.
> >>
> >> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
> >> ---
> >> arch/arm/mach-snapdragon/board.c | 86 +++++++++++++++++++++++++---------------
> >> 1 file changed, 53 insertions(+), 33 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
> >> index 829a0109ac78..e12d3d00caa4 100644
> >> --- a/arch/arm/mach-snapdragon/board.c
> >> +++ b/arch/arm/mach-snapdragon/board.c
> >> @@ -622,27 +622,36 @@ u64 get_page_table_size(void)
> >> {
> >> return SZ_1M;
> >> }
> >>
> >> +struct mem_resource_attrs {
> >> + fdt_addr_t start;
> >> + fdt_addr_t size;
> >> + u64 attrs;
> >> +};
> >
> > Let's move the struct declaration towards the top.
>
> it's only used by this one function, it felt easier to keep things
> readable this way. Probably we'll move this stuff to its own file at
> some point.
>
> >
> >> +
> >> static int fdt_cmp_res(const void *v1, const void *v2)
> >
> > This API should now be renamed as mem_cmp_resources(), no?
>
> yeah
>
> >
> >> {
> >> - const struct fdt_resource *res1 = v1, *res2 = v2;
> >> + const struct mem_resource_attrs *res1 = v1, *res2 = v2;
> >>
> >> return res1->start - res2->start;
> >> }
> >>
> >> -#define N_RESERVED_REGIONS 32
> >> +#define N_RESERVED_REGIONS 64
> >>
> >> -/* Mark all no-map regions as PTE_TYPE_FAULT to prevent speculative access.
> >> +/* Map and unmap reserved memory regions as appropriate.
> >> + * Mark all no-map regions as PTE_TYPE_FAULT to prevent speculative access.
> >> * On some platforms this is enough to trigger a security violation and trap
> >> * to EL3.
> >> + * Regions that may be accessed by drivers get mapped explicitly.
> >> */
> >> -static void carve_out_reserved_memory(void)
> >> +static void configure_reserved_memory(void)
> >> {
> >> - static struct fdt_resource res[N_RESERVED_REGIONS] = { 0 };
> >> + static struct mem_resource_attrs res[N_RESERVED_REGIONS] = { 0 };
> >> int parent, rmem, count, i = 0;
> >> phys_addr_t start;
> >> size_t size;
> >> + u64 attrs;
> >>
> >> /* Some reserved nodes must be carved out, as the cache-prefetcher may otherwise
> >> * attempt to access them, causing a security exception.
> >> */
> >> @@ -651,14 +660,19 @@ static void carve_out_reserved_memory(void)
> >> log_err("No reserved memory regions found\n");
> >> return;
> >> }
> >>
> >> - /* Collect the reserved memory regions */
> >> + /* Collect the reserved memory regions and appropriate attrs */
> >> fdt_for_each_subnode(rmem, gd->fdt_blob, parent) {
> >> const fdt32_t *ptr;
> >> - int len;
> >> + attrs = PTE_TYPE_FAULT;
> >> + /* If the no-map property isn't set then the region is valid */
> >> if (!fdt_getprop(gd->fdt_blob, rmem, "no-map", NULL))
> >> - continue;
> >> + attrs = PTE_TYPE_VALID | PTE_BLOCK_MEMTYPE(MT_NORMAL);
> >> + /* If the compatible property is set then this region may be accessed by drivers and should
> >> + * be marked valid too. */
> >> + if (fdt_getprop(gd->fdt_blob, rmem, "compatible", NULL))
> >> + attrs = PTE_TYPE_VALID | PTE_BLOCK_MEMTYPE(MT_NORMAL);
> >>
> >> if (i == N_RESERVED_REGIONS) {
> >> log_err("Too many reserved regions!\n");
> >> break;
> >> @@ -667,50 +681,55 @@ static void carve_out_reserved_memory(void)
> >> /* Read the address and size out from the reg property. Doing this "properly" with
> >> * fdt_get_resource() takes ~70ms on SDM845, but open-coding the happy path here
> >> * takes <1ms... Oh the woes of no dcache.
> >> */
> >> - ptr = fdt_getprop(gd->fdt_blob, rmem, "reg", &len);
> >> + ptr = fdt_getprop(gd->fdt_blob, rmem, "reg", NULL);
> >> if (ptr) {
> >> /* Qualcomm devices use #address/size-cells = <2> but all reserved regions are within
> >> * the 32-bit address space. So we can cheat here for speed.
> >> */
> >> res[i].start = fdt32_to_cpu(ptr[1]);
> >> - res[i].end = res[i].start + fdt32_to_cpu(ptr[3]);
> >> + res[i].size = fdt32_to_cpu(ptr[3]);
> >> + res[i].attrs = attrs;
> >> i++;
> >> }
> >> }
> >>
> >> /* Sort the reserved memory regions by address */
> >> count = i;
> >> - qsort(res, count, sizeof(struct fdt_resource), fdt_cmp_res);
> >> + qsort(res, count, sizeof(res[0]), fdt_cmp_res);
> >> + debug("Mapping %d regions!\n", count);
> >>
> >> /* Now set the right attributes for them. Often a lot of the regions are tightly packed together
> >> - * so we can optimise the number of calls to mmu_change_region_attr() by combining adjacent
> >> + * so we can optimise the number of calls to mmu_change_region_attr_nobreak() by combining adjacent
> >> * regions.
> >> */
> >> - start = ALIGN_DOWN(res[0].start, SZ_2M);
> >> - size = ALIGN(res[0].end - start, SZ_2M);
> >> + start = res[0].start;
> >> + size = res[0].size;
> >> + attrs = res[0].attrs;
> >> + /* For each region after the first one, either increase the `size` to eventually be mapped or
> >> + * map the region we have and start a new one, this allows us to reduce the number of calls to
> >> + * mmu_map_region(). The loop is therefore "lagging" behind by one iteration. */
> >> for (i = 1; i <= count; i++) {
> >> - /* We ideally want to 2M align everything for more efficient pagetables, but we must avoid
> >> - * overwriting reserved memory regions which shouldn't be mapped as FAULT (like those with
> >> - * compatible properties).
> >> - * If within 2M of the previous region, bump the size to include this region. Otherwise
> >> - * start a new region.
> >> - */
> >> - if (i == count || start + size < res[i].start - SZ_2M) {
> >> - debug(" 0x%016llx - 0x%016llx: reserved\n",
> >> - start, start + size);
> >> - mmu_change_region_attr(start, size, PTE_TYPE_FAULT);
> >> - /* If this is the final region then quit here before we index
> >> - * out of bounds...
> >> - */
> >> + /* If i == count we are done, just map the last region. If the last region is
> >> + * too far away or the attrs don't match then map the meta-region we have and
> >> + * start a new one. */
> >> + if (i == count || start + size < res[i].start - SZ_8K || attrs != res[i].attrs) {
> >
> > I suppose this SZ_8K instead of SZ_2M is intentional here? It works now
> > due to page table optimization I guess?
>
> I realised there was a possibility for incorrectly mapping stuff with
> 2M. Probably not with the logic as it is but e.g. if you don't
> explicitly map reserved regions that need to be mapped then they can get
> unmapped here.
I think we rather need to unmap all the no-map regions first via
aligning to 2MB block mappings and then map regions required to be
mapped with the needed granularity. This way we can optimize the page
tables usage.
-Sumit
next prev parent reply other threads:[~2026-05-07 7:45 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 18:57 [PATCH v2 00/15] qcom: smem: modernize SMEM in U-Boot Casey Connolly
2026-05-04 18:57 ` [PATCH v2 01/15] Revert "dm: SMEM (Shared memory) uclass" Casey Connolly
2026-05-05 10:15 ` Sumit Garg
2026-05-07 15:31 ` Simon Glass
2026-05-07 20:05 ` Casey Connolly
2026-05-18 14:34 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 02/15] smem: drop drivers/smem Casey Connolly
2026-05-18 14:34 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 03/15] Revert "test: smem: add basic smem test" Casey Connolly
2026-05-05 10:26 ` Sumit Garg
2026-05-18 14:34 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 04/15] Revert "drivers: smem: sandbox" Casey Connolly
2026-05-05 10:26 ` Sumit Garg
2026-05-18 14:34 ` Neil Armstrong
2026-05-18 15:51 ` Fabio Estevam
2026-05-04 18:57 ` [PATCH v2 05/15] mach-snapdragon: fix reserved memory carveout Casey Connolly
2026-05-05 12:25 ` Sumit Garg
2026-05-05 12:39 ` Casey Connolly
2026-05-07 7:45 ` Sumit Garg [this message]
2026-05-07 20:29 ` Casey Connolly
2026-05-04 18:57 ` [PATCH v2 06/15] soc: qcom: import smem from Linux 6.11-rc2 Casey Connolly
2026-05-05 12:40 ` Sumit Garg
2026-05-05 12:45 ` Casey Connolly
2026-05-18 14:36 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 07/15] soc: qcom: smem: adjust headers for U-Boot Casey Connolly
2026-05-05 12:43 ` Sumit Garg
2026-05-18 14:36 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 08/15] soc: qcom: smem: adjust " Casey Connolly
2026-05-08 10:43 ` Aswin Murugan
2026-05-11 12:22 ` Casey Connolly
2026-05-18 11:03 ` Sumit Garg
2026-05-04 18:57 ` [PATCH v2 09/15] soc: qcom: smem: get serial number from socinfo Casey Connolly
2026-05-18 12:49 ` Sumit Garg
2026-05-04 18:57 ` [PATCH v2 10/15] soc: qcom: smem: stub functions Casey Connolly
2026-05-18 14:37 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 11/15] soc: qcom: smem: add build infra Casey Connolly
2026-05-18 12:53 ` Sumit Garg
2026-05-18 14:38 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 12/15] mach-snapdragon: move memory parsing to its own file Casey Connolly
2026-05-18 12:54 ` Sumit Garg
2026-05-18 14:40 ` Neil Armstrong
2026-05-04 18:57 ` [PATCH v2 13/15] mach-snapdragon: support parsing memory map from SMEM Casey Connolly
2026-05-18 14:48 ` Neil Armstrong
2026-05-21 13:36 ` Stephan Gerhold
2026-05-04 18:57 ` [PATCH v2 14/15] mach-snapdragon: fetch serial# " Casey Connolly
2026-05-18 13:15 ` Sumit Garg
2026-05-04 18:57 ` [PATCH v2 15/15] configs: add qcom_sm8650_defconfig and debug fragment Casey Connolly
2026-05-05 6:45 ` Luca Weiss
2026-05-05 10:11 ` [PATCH v2 00/15] qcom: smem: modernize SMEM in U-Boot Sumit Garg
2026-05-05 12:25 ` Casey Connolly
2026-05-05 12:35 ` Sumit Garg
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=afxDHAZD25moYKg8@sumit-xelite \
--to=sumit.garg@kernel.org \
--cc=alice.guo@nxp.com \
--cc=aswin.murugan@oss.qualcomm.com \
--cc=balaji.selvanathan@oss.qualcomm.com \
--cc=casey.connolly@linaro.org \
--cc=hs@nabladev.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jerome.forissier@arm.com \
--cc=linux@smankusors.com \
--cc=luca.weiss@fairphone.com \
--cc=marek.vasut+renesas@mailbox.org \
--cc=marek.vasut@mailbox.org \
--cc=michal.simek@amd.com \
--cc=mkorpershoek@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=patrice.chotard@foss.st.com \
--cc=peng.fan@nxp.com \
--cc=philip.molloy@analog.com \
--cc=quentin.schulz@cherry.de \
--cc=ravi@prevas.dk \
--cc=raymond.mao@riscstar.com \
--cc=sjg@chromium.org \
--cc=stefan.roese@mailbox.org \
--cc=sughosh.ganu@arm.com \
--cc=trini@konsulko.com \
--cc=u-boot-qcom@groups.io \
--cc=u-boot@lists.denx.de \
--cc=varadarajan.narayanan@oss.qualcomm.com \
--cc=visitorckw@gmail.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.