All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: "Orzel, Michal" <michal.orzel@amd.com>
Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org,
	julien@xen.org, bertrand.marquis@arm.com, marscheng@google.com,
	jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com
Subject: Re: [PATCH] xen/dt: Skip non-RAM reserved-memory regions in make_memory_node()
Date: Sat, 31 Oct 2026 05:58:23 +0800	[thread overview]
Message-ID: <auUS_7jNO-0ONE1e@google.com> (raw)
In-Reply-To: <d25a667b-5126-4c57-b379-c31c4e7645c6@amd.com>

Hi Michal,

On Fri, Oct 30, 2026 at 12:04:58PM +0100, Orzel, Michal wrote:
> 
> 
> On 28-Oct-26 22:17, Kuan-Wei Chiu wrote:
> > Xen creates a second /memory node for Dom0 from
> > bootinfo_get_reserved_mem() without checking whether those regions
> > belong to host RAM. However, /reserved-memory can also describe
> > on-chip SRAM or firmware regions outside system RAM. Listing them in a
> > /memory node causes Dom0 to register non-RAM addresses as system RAM,
> > conflicting with device MMIO mappings.
> Hmm, I always thought that /reserved-memory is to exclude regions from memory
> described under /memory. That's what Xen assumes too. map_range_to_domain() for
> example does not call iomem_permit_access() for such regions because we assume
> it's RAM. Can you provide more details of your board e.g. the device tree? Is
> there any documentation I could use to confirm that "reserved-memory can also
> describe on-chip SRAM or firmware regions outside system RAM"?
> 
Hmm, your reply initially made me wonder if this was caused by a
non-compliant downstream device tree on our side, so I checked the
DT spec and upstream Linux.

The devicetree spec does not seem to explicitly mention whether
/reserved-memory regions must fall within the range described by
/memory. From a quick look at early_init_dt_reserve_memory() in Linux,
the comment there also mentions not worrying if a no-map region is not
memory as it will not be mapped.

In upstream Linux device trees, there are cases like
arch/mips/boot/dts/mobileye/eyeq5.dtsi and eyeq5-epm5.dts, where
/memory starts at 0x40000000 and 0x802000000, while /reserved-memory
defines an on-chip sram region nvram@461fe00 with "nvmem-rmem" outside
/memory.

Our board's device tree is not upstream yet, but it follows a similar
pattern where /reserved-memory defines "nvmem-rmem" and dma pool
sub-regions inside on-chip sram outside the dram range described by
/memory.

Regards,
Kuan-Wei


      reply	other threads:[~2026-10-30 21:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-28 21:17 [PATCH] xen/dt: Skip non-RAM reserved-memory regions in make_memory_node() Kuan-Wei Chiu
2026-10-30 11:04 ` Orzel, Michal
2026-10-30 21:58   ` Kuan-Wei Chiu [this message]

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=auUS_7jNO-0ONE1e@google.com \
    --to=visitorckw@gmail.com \
    --cc=bertrand.marquis@arm.com \
    --cc=eleanor15x@gmail.com \
    --cc=jserv@ccns.ncku.edu.tw \
    --cc=julien@xen.org \
    --cc=marscheng@google.com \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.