[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y02vm7FrhdEoSXZ+@spud>
Date: Mon, 17 Oct 2022 20:40:11 +0100
From: Conor Dooley <conor@...nel.org>
To: Xianting Tian <xianting.tian@...ux.alibaba.com>
Cc: paul.walmsley@...ive.com, palmer@...belt.com,
aou@...s.berkeley.edu, anup@...infault.org, heiko@...ech.de,
guoren@...nel.org, mick@....forth.gr,
alexandre.ghiti@...onical.com, bhe@...hat.com, vgoyal@...hat.com,
dyoung@...hat.com, corbet@....net, Conor.Dooley@...rochip.com,
bagasdotme@...il.com, kexec@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, crash-utility@...hat.com,
heinrich.schuchardt@...onical.com, k-hagio-ab@....com,
hschauhan@...ltrace.org, yixun.lan@...il.com
Subject: Re: [PATCH V2 2/2] Documentation: kdump: describe VMCOREINFO export
for RISCV64
On Fri, Oct 14, 2022 at 09:41:39PM +0800, Xianting Tian wrote:
> The following interrelated definitions and ranges are needed by the kdump
> crash tool, they are exported by "arch/riscv/kernel/crash_core.c":
> VA_BITS,
> PAGE_OFFSET,
> phys_ram_base,
> MODULES_VADDR ~ MODULES_END,
> VMALLOC_START ~ VMALLOC_END,
> VMEMMAP_START ~ VMEMMAP_END,
> KASAN_SHADOW_START ~ KASAN_SHADOW_END,
> KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END
>
> Document these RISCV64 exports above.
>
> Signed-off-by: Xianting Tian <xianting.tian@...ux.alibaba.com>
> ---
> .../admin-guide/kdump/vmcoreinfo.rst | 30 +++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> index 6726f439958c..8e2e164cf3db 100644
> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> @@ -595,3 +595,33 @@ X2TLB
> -----
>
> Indicates whether the crashed kernel enabled SH extended mode.
> +
> +RISCV64
> +=======
> +
> +VA_BITS
> +-------
> +
> +The maximum number of bits for virtual addresses. Used to compute the
> +virtual memory ranges.
> +
> +PAGE_OFFSET
> +-----------
> +
> +Indicates the virtual kernel start address of direct-mapped RAM region.
Apologies for not seeing this sooner, but should there not be a "the"
prior to "direct-mapped"?
> +
> +phys_ram_base
> +-------------
> +
> +Indicates the start physical RAM address.
> +
> +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
> +----------------------------------------------------------------------------------------------------------------------------------------------------
> +
> +Used to get the correct ranges:
> +
> + * MODULES_VADDR ~ MODULES_END : Kernel module space.
> + * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
> + * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
Since I'm in pedant mode, it does look a little odd that you're using
region for vmemmap but space for the others but idc that much.
Thanks,
Conor.
> + * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
> + * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
> --
> 2.17.1
>
>
Powered by blists - more mailing lists