Hi
vmemmap and VMEMMAP_START are different,vmemmap begin from physical address 0x0 of
page,but VMEMMAP_START start with memstart_addr.
[mm/init.c]
arm64_memblock_init
348 vmemmap = ((struct page *)VMEMMAP_START - (memstart_addr >>
PAGE_SHIFT));
We can look at address_markers,this symbol indicates the entire memory map allocation
check vmemmap and address_markers, we can see vmemmap has out of vmemmap range
crash> p -x vmemmap
vmemmap = $1 = (struct page *) 0xfffffffefde00000
address_markers = $2 =
{{
start_address = 0xffffff8000000000,
name = 0xffffffd44b1fed8f "Linear Mapping start"
...
}, {
start_address = 0xfffffffeffe00000,
name = 0xffffffd44b2c5beb "vmemmap start"
}, {
start_address = 0xffffffffffe00000,
name = 0xffffffd44b1eb00c "vmemmap end"
}, {
start_address = 0xffffffffffffffff,
name = 0x0
}}
When the readmem() of symbol_value("physvirt_offset") is
made, arm64_VTOP() will
be called with its virtual address, right?
Yes,arm64_VTOP to get physvirt_offset
needs virtual address,and physvirt_offset is a kimage symbol,so just need kimage_voffset
can translate to physical address,then get value of physvirt_offset.
physvirt_offset just two value in different kernel
version,"phys_offset-page_offset" or physvirt_offset,so after initialize
ms->physvirt_offset to different value,we can use ms->physvirt_offset for vtop/ptov
for Linner mapping.
________________________________________
From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com> on behalf
of Dave Anderson <anderson(a)redhat.com>
Sent: Sunday, April 19, 2020 23:30
To: Discussion list for crash utility usage, maintenance and development
Subject: [营销邮件] Re: [Crash-utility] [营销邮件] Re: [External Mail][????] Re: ramdump support
for va_bits_actual
----- Original Message -----
Hi,Dave
I don't quite understand how you said to read vmemmap,VMEMMAP_START is a
macro definition,or it's a constant,in crash-utility vmemmap_start is a
wrong value,this may cause arm64_IS_VMALLOC_ADDR return wrong status
I mean the kernel symbol "vmemmap", here in "arch/arm64/mm/init.c":
struct page *vmemmap __ro_after_init;
EXPORT_SYMBOL(vmemmap);
Doesn't it contain the resolved starting address?
We can get physvirt_offset earlier,in my patch,after calling
arm64_calc_phys_offset we can initialize physvirt_offset,in this
time,kimage_offset,page_offset and phys_offset are ready,such as:
@@ -391,6 +391,13 @@ arm64_init(int when)
ms = machdep->machspec;
+ if (kernel_symbol_exists("physvirt_offset") &&
+ readmem(symbol_value("physvirt_offset"), KVADDR,
+ &value, sizeof(ulong), "physvirt_offset",
QUIET|RETURN_ON_ERROR))
+ ms->physvirt_offset = value;
+ else
+ ms->physvirt_offset = ms->phys_offset ->
ms->page_offset;
When the readmem() of symbol_value("physvirt_offset") is made, arm64_VTOP()
will
be called with its virtual address, right?
Dave
________________________________________
From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com> on
behalf of Dave Anderson <anderson(a)redhat.com>
Sent: Sunday, April 19, 2020 1:03
To: Discussion list for crash utility usage, maintenance and development
Subject: [营销邮件] Re: [Crash-utility] [External Mail][????] Re: ramdump support
for va_bits_actual
----- Original Message -----
> Hi
> I made almost the same patch to fix the problem with arm64 in version
> 5.4...
>
> One very small change can merged together,vmemmap_start has a little error:
> [arch/arm64/include/asm/memory.h]
> 56 #define VMEMMAP_START (-VMEMMAP_SIZE - SZ_2M)
> in crash arm64.c
> - vmemmap_start = (-vmemmap_size);
> + vmemmap_start = (-vmemmap_size - MEGABYTES(2));
Can't we just read the value of "vmemmap"? If not, what is the difference
between the calculated value above and the value of vmemmap?
>
>
> BTW,in arm64_VTOP,it's easier to use the physvirt_offset directly
> @@ -1148,8 +1155,7 @@ arm64_VTOP(ulong addr)
>
> }
>
> if (addr >= machdep->machspec->page_offset)
> - return machdep->machspec->phys_offset
> - + (addr - machdep->machspec->page_offset);
> + return (addr + machdep->machspec->physvirt_offset);
Unfortunately that's not possible, because there is at least one arm64_VTOP()
call *before* the new machdep->machspec->physvirt_offset gets initialized,
which I presume is why Vinayak's patch checks whether it's non-zero first.
Dave
> ________________________________________
> From: crash-utility-bounces(a)redhat.com <crash-utility-bounces(a)redhat.com>
> on
> behalf of Dave Anderson <anderson(a)redhat.com>
> Sent: Saturday, April 18, 2020 0:32
> To: Discussion list for crash utility usage, maintenance and development
> Subject: [External Mail][????] Re: [Crash-utility] ramdump support for
> va_bits_actual
>
> ----- Original Message -----
> > Hi Dave,
> >
> > Noticed that raw ramdumps of 5.4 kernel aren't working with crash tip.
> > With the patches attached, I could get it working. Please take a look.
> >
> > Thanks,
> > Vinayak
> >
>
> Hi Vinayak,
>
> A couple quick questions come to mind...
>
> First, I haven't checked all possible READMEM plugins, but for example, if
> this
> function is run on a live system, the -1 file descriptor would cause the
> READMEM()
> call to fail:
>
> static void
> +arm64_calc_physvirt_offset(void)
> +{
> + struct machine_specific *ms = machdep->machspec;
> + ulong physvirt_offset;
> + struct syment *sp;
> +
> + ms->physvirt_offset = ms->phys_offset - ms->page_offset;
> +
> + if ((sp = kernel_symbol_search("physvirt_offset")) &&
> + machdep->machspec->kimage_voffset) {
> + if (READMEM(-1, &physvirt_offset, sizeof(physvirt_offset),
> + sp->value, sp->value -
> + machdep->machspec->kimage_voffset) > 0) {
> + ms->physvirt_offset = physvirt_offset;
> + }
> + }
> +
> + if (CRASHDEBUG(1))
> + fprintf(fp, "using %lx as physvirt_offset\n",
> ms->physvirt_offset);
> +}
>
> And here -- are you missing some brackets? (run "make warn")
>
> But regardless of that, why are you setting it back to 48 if it's greater
> than 48?
>
> diff --git a/arm64.c b/arm64.c
> index 31d6e90..04efc13 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -4011,6 +4011,7 @@ arm64_calc_virtual_memory_ranges(void)
> struct machine_specific *ms = machdep->machspec;
> ulong value, vmemmap_start, vmemmap_end, vmemmap_size, vmalloc_end;
> char *string;
> + int ret;
> ulong PUD_SIZE = UNINITIALIZED;
>
> if (!machdep->machspec->CONFIG_ARM64_VA_BITS) {
> @@ -4018,6 +4019,12 @@ arm64_calc_virtual_memory_ranges(void)
> value = atol(string);
> free(string);
> machdep->machspec->CONFIG_ARM64_VA_BITS = value;
> + } else if (kt->ikconfig_flags & IKCONFIG_AVAIL) {
> + if ((ret =
> get_kernel_config("CONFIG_ARM64_VA_BITS",
> + &string)) == IKCONFIG_STR)
> + machdep->machspec->CONFIG_ARM64_VA_BITS =
> atol(string);
> + if (machdep->machspec->CONFIG_ARM64_VA_BITS
> >
> 48)
> +
> machdep->machspec->CONFIG_ARM64_VA_BITS
> = 48;
> }
> }
>
> Thanks,
> Dave
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/crash-utility
>
>
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> XIAOMI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by
> phone or email immediately and delete it!******/#
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from
XIAOMI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!******/#
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from XIAOMI, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!******/#