From: Nick Kossifidis <mick@ics.forth.gr>
To: Zong Li <zong.li@sifive.com>
Cc: paul.walmsley@sifive.com, palmer@dabbelt.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] riscv: Register System RAM as iomem resources
Date: Tue, 16 Jun 2020 14:51:53 +0300 [thread overview]
Message-ID: <0e1d7a917332b90666417ac0508f8a6d@mailhost.ics.forth.gr> (raw)
In-Reply-To: <063fab26f4c15bf5b833b57fa818749afa7811d4.1592292685.git.zong.li@sifive.com>
Στις 2020-06-16 10:45, Zong Li έγραψε:
> Add System RAM to /proc/iomem, various tools expect it such as kdump.
> It is also needed for page_is_ram API which checks the specified
> address
> whether registered as System RAM in iomem_resource list.
>
> Signed-off-by: Zong Li <zong.li@sifive.com>
> ---
> arch/riscv/mm/init.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index f4adb3684f3d..bbe816e03b2f 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -517,6 +517,27 @@ void mark_rodata_ro(void)
> }
> #endif
>
> +void __init resource_init(void)
> +{
> + struct memblock_region *region;
> +
> + for_each_memblock(memory, region) {
> + struct resource *res;
> +
> + res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
> + if (!res)
> + panic("%s: Failed to allocate %zu bytes\n", __func__,
> + sizeof(struct resource));
> +
> + res->name = "System RAM";
> + res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> + res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) -
> 1;
> + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> +
> + request_resource(&iomem_resource, res);
> + }
> +}
> +
> void __init paging_init(void)
> {
> setup_vm_final();
> @@ -524,6 +545,7 @@ void __init paging_init(void)
> sparse_init();
> setup_zero_page();
> zone_sizes_init();
> + resource_init();
> }
>
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
I already have a patch for registering System RAM as an iomem resource
on my kexec/kdump series. Since I don't care about System RAM regions
being accurately exposed to userspace (I parse the current device tree
instead) I just use memblock_start_of_DRAM/end_of_DRAM. This approach
from arm64 codebase is better since it also handles the case of sparse
memory regions but in order to be useful for kdump we need to add the
various segments of the kernel image as child nodes to their respective
region for kexec-tools. I'll re-spin my patchset anyway so I'll extend
it to better handle System RAM regions.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Kossifidis <mick@ics.forth.gr>
To: Zong Li <zong.li@sifive.com>
Cc: linux-riscv@lists.infradead.org, palmer@dabbelt.com,
linux-kernel@vger.kernel.org, paul.walmsley@sifive.com
Subject: Re: [PATCH 1/2] riscv: Register System RAM as iomem resources
Date: Tue, 16 Jun 2020 14:51:53 +0300 [thread overview]
Message-ID: <0e1d7a917332b90666417ac0508f8a6d@mailhost.ics.forth.gr> (raw)
In-Reply-To: <063fab26f4c15bf5b833b57fa818749afa7811d4.1592292685.git.zong.li@sifive.com>
Στις 2020-06-16 10:45, Zong Li έγραψε:
> Add System RAM to /proc/iomem, various tools expect it such as kdump.
> It is also needed for page_is_ram API which checks the specified
> address
> whether registered as System RAM in iomem_resource list.
>
> Signed-off-by: Zong Li <zong.li@sifive.com>
> ---
> arch/riscv/mm/init.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index f4adb3684f3d..bbe816e03b2f 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -517,6 +517,27 @@ void mark_rodata_ro(void)
> }
> #endif
>
> +void __init resource_init(void)
> +{
> + struct memblock_region *region;
> +
> + for_each_memblock(memory, region) {
> + struct resource *res;
> +
> + res = memblock_alloc(sizeof(struct resource), SMP_CACHE_BYTES);
> + if (!res)
> + panic("%s: Failed to allocate %zu bytes\n", __func__,
> + sizeof(struct resource));
> +
> + res->name = "System RAM";
> + res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> + res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) -
> 1;
> + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> +
> + request_resource(&iomem_resource, res);
> + }
> +}
> +
> void __init paging_init(void)
> {
> setup_vm_final();
> @@ -524,6 +545,7 @@ void __init paging_init(void)
> sparse_init();
> setup_zero_page();
> zone_sizes_init();
> + resource_init();
> }
>
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
I already have a patch for registering System RAM as an iomem resource
on my kexec/kdump series. Since I don't care about System RAM regions
being accurately exposed to userspace (I parse the current device tree
instead) I just use memblock_start_of_DRAM/end_of_DRAM. This approach
from arm64 codebase is better since it also handles the case of sparse
memory regions but in order to be useful for kdump we need to add the
various segments of the kernel image as child nodes to their respective
region for kexec-tools. I'll re-spin my patchset anyway so I'll extend
it to better handle System RAM regions.
next prev parent reply other threads:[~2020-06-16 11:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 7:45 [PATCH 0/2] Add STRICT_DEVMEM support on RISC-V Zong Li
2020-06-16 7:45 ` [PATCH 1/2] riscv: Register System RAM as iomem resources Zong Li
2020-06-16 11:51 ` Nick Kossifidis [this message]
2020-06-16 11:51 ` Nick Kossifidis
2020-06-17 1:23 ` Zong Li
2020-06-17 1:23 ` Zong Li
2020-07-09 18:27 ` Palmer Dabbelt
2020-07-09 18:27 ` Palmer Dabbelt
2020-07-10 2:05 ` Nick Kossifidis
2020-07-10 2:05 ` Nick Kossifidis
2020-06-16 7:45 ` [PATCH 2/2] riscv: Support CONFIG_STRICT_DEVMEM Zong Li
2020-06-16 12:27 ` Nick Kossifidis
2020-06-16 12:27 ` Nick Kossifidis
2020-06-17 1:56 ` Zong Li
2020-06-17 1:56 ` Zong Li
2020-06-17 5:28 ` Nick Kossifidis
2020-06-17 5:28 ` Nick Kossifidis
2020-06-17 6:32 ` Zong Li
2020-06-17 6:32 ` Zong Li
2020-07-09 20:08 ` Palmer Dabbelt
2020-07-09 20:08 ` Palmer Dabbelt
2020-07-10 2:43 ` Zong Li
2020-07-10 2:43 ` Zong Li
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=0e1d7a917332b90666417ac0508f8a6d@mailhost.ics.forth.gr \
--to=mick@ics.forth.gr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=zong.li@sifive.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.