[Crash-utility] [PATCH V2] RISCV64: Use va_kernel_pa_offset in VTOP()

lijiang lijiang at redhat.com
Mon Aug 14 08:27:48 UTC 2023


Thank you for the update, Song.
On Mon, Aug 14, 2023 at 9:54 AM <crash-utility-request at redhat.com> wrote:

> Date: Fri,  4 Aug 2023 17:15:59 +0800
> From: Song Shuai <suagrfillet at gmail.com>
> To: xianting.tian at linux.alibaba.com, mick at ics.forth.gr,
>         heinrich.schuchardt at canonical.com, guoren at kernel.org,
>         k-hagio-ab at nec.com, yixun.lan at gmail.com, lijiang at redhat.com
> Cc: linux-riscv at lists.infradead.org, kexec at lists.infradead.org,
>         crash-utility at redhat.com, Song Shuai <suagrfillet at gmail.com>
> Subject: [Crash-utility] [Crash-utility PATCH V2] RISCV64: Use
>         va_kernel_pa_offset in VTOP()
> Message-ID: <20230804091559.3005820-1-suagrfillet at gmail.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use
> PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base from
> the physical start of the kernel to the actual start of the DRAM.
>
> The Crash's VTOP() still uses phys_ram_base and kernel_map.virt_addr
> to translate kernel virtual address, that made Crash boot failed with
> Linux v6.4 and later version.
>
> Let Linux export kernel_map.va_kernel_pa_offset in v6.5 and backported
> v6.4.0 stable, so Crash can use "va_kernel_pa_offset" to translate the
> kernel virtual address in VTOP() correctly.
>
> Signed-off-by: Song Shuai <suagrfillet at gmail.com>
> ---
> Changes since V1:
>   - remove unnecessary first kernel version check as Kazu suggested
>   - amend the commit-msg as Alex suggested
> ---
>  defs.h    |  4 ++--
>  riscv64.c | 23 +++++++++++++++++++++++
>  2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/defs.h b/defs.h
> index 5ee60f1..c07e6d7 100644
> --- a/defs.h
> +++ b/defs.h
> @@ -3662,8 +3662,7 @@ typedef signed int s32;
>         ulong _X = X;
>              \
>         (THIS_KERNEL_VERSION >= LINUX(5,13,0) &&
>               \
>                 (_X) >= machdep->machspec->kernel_link_addr) ?
>               \
> -               (((unsigned
> long)(_X)-(machdep->machspec->kernel_link_addr)) +          \
> -                machdep->machspec->phys_base):
>              \
> +               ((unsigned
> long)(_X)-(machdep->machspec->va_kernel_pa_offset)):         \
>                 (((unsigned long)(_X)-(machdep->kvbase)) +
>               \
>                  machdep->machspec->phys_base);
>              \
>         })
> @@ -7021,6 +7020,7 @@ struct machine_specific {
>         ulong modules_vaddr;
>         ulong modules_end;
>         ulong kernel_link_addr;
> +       ulong va_kernel_pa_offset;
>
>         ulong _page_present;
>         ulong _page_read;
> diff --git a/riscv64.c b/riscv64.c
> index 6b9a688..7b5dd3d 100644
> --- a/riscv64.c
> +++ b/riscv64.c
> @@ -418,6 +418,28 @@ error:
>         error(FATAL, "cannot get vm layout\n");
>  }
>
> +static void
> +riscv64_get_va_kernel_pa_offset(struct machine_specific *ms)
> +{
> +       unsigned long kernel_version = riscv64_get_kernel_version();
> +
> +       /*
> +        * Since Linux v6.4 phys_base is not the physical start of the
> kernel,
> +        * trying to use "va_kernel_pa_offset" to determine the offset
> between
> +        * kernel virtual and physical addresses.
> +        */
> +       if (kernel_version >= LINUX(6,4,0)) {
>

Is it possible to detect the existence of the symbol
'linear_mapping_va_to_pa' or 'linear_mapping_pa_to_va' to decide reading
the value of 'va_kernel_pa_offset'? For example:
kernel_symbol_exists()/symbol_exists()

if (kernel_symbol_exists("linear_mapping_va_to_pa") ||
kernel_symbol_exists("linear_mapping_pa_to_va")) {
    string = pc->read_vmcoreinfo("NUMBER(va_kernel_pa_offset)");
    ...
}

I saw the commit 3335068f8721 exported two symbols:

+phys_addr_t linear_mapping_va_to_pa(unsigned long x)
+{
+       BUG_ON(!kernel_map.va_pa_offset);
+
+       return ((unsigned long)(x) - kernel_map.va_pa_offset);
+}
+EXPORT_SYMBOL(linear_mapping_va_to_pa);
+
+void *linear_mapping_pa_to_va(unsigned long x)
+{
+       BUG_ON(!kernel_map.va_pa_offset);
+
+       return ((void *)((unsigned long)(x) + kernel_map.va_pa_offset));
+}
+EXPORT_SYMBOL(linear_mapping_pa_to_va);

Thanks.
Lianbo

+               char *string;
> +               if ((string =
> pc->read_vmcoreinfo("NUMBER(va_kernel_pa_offset)"))) {
> +                       ms->va_kernel_pa_offset = htol(string, QUIET,
> NULL);
> +                       free(string);
> +               } else
> +                       error(FATAL, "cannot read va_kernel_pa_offset\n");
> +       }
> +       else
> +               ms->va_kernel_pa_offset = ms->kernel_link_addr -
> ms->phys_base;
> +}
> +
>  static int
>  riscv64_is_kvaddr(ulong vaddr)
>  {
> @@ -1352,6 +1374,7 @@ riscv64_init(int when)
>                 riscv64_get_struct_page_size(machdep->machspec);
>                 riscv64_get_va_bits(machdep->machspec);
>                 riscv64_get_va_range(machdep->machspec);
> +               riscv64_get_va_kernel_pa_offset(machdep->machspec);
>
>                 pt_level_alloc(&machdep->pgd, "cannot malloc pgd space.");
>                 pt_level_alloc(&machdep->machspec->p4d, "cannot malloc p4d
> space.");
> --
> 2.20.1
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20230814/8c5ec122/attachment.htm>


More information about the Crash-utility mailing list