Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
On Mon, Jan 27, 2020 at 02:24:50PM -0500, Dave Anderson wrote: > > > - Original Message - > > On Mon, Jan 27, 2020 at 12:15:48PM -0500, Dave Anderson wrote: > > > > > > > > > - Original Message - > > > ... > > > > > > > > Thanks, I didn't know qemu has '-device vmcoreinfo' option. > > > > > > > > It seems that the vmcoreinfo option works for aarch64 as well. > > > > The KASLR issue and the modules_vaddr issue are gone with > > > > vmcoreinfo option. Great! > > > > > > > > However, VA_BITS issue still remains the vmcoreinfo doesn't have > > > > 'NUMBER(tcr_el1_t1sz)'. > > > > I suppose we can use 'NUMBER(VA_BITS)' instead, so I'll post another > > > > patch later. > > > > > > Right -- Bhupesh is still working on getting NUMBER(tcr_el1_t1sz) > > > accepted upstream. > > > > Great! > > So, should we wait Bhupesh's patch is merged to upstream? > > Or, is useful following workaround patch until then? > > > > diff --git a/arm64.c b/arm64.c > > index 7662d71..bf93404 100644 > > --- a/arm64.c > > +++ b/arm64.c > > @@ -3889,6 +3889,14 @@ arm64_calc_VA_BITS(void) > > machdep->machspec->VA_BITS_ACTUAL = value; > > machdep->machspec->VA_BITS = value; > > machdep->machspec->VA_START = > > > > _VA_START(machdep->machspec->VA_BITS_ACTUAL); > > + } else if ((string = > > pc->read_vmcoreinfo("NUMBER(VA_BITS)"))) { > > + value = strtoll(string, NULL, 0); > > + if (CRASHDEBUG(1)) > > + fprintf(fp, "vmcoreinfo : > > vabits_actual: %ld\n", value); > > + free(string); > > + machdep->machspec->VA_BITS_ACTUAL = value; > > + machdep->machspec->VA_BITS = value; > > + machdep->machspec->VA_START = > > _VA_START(machdep->machspec->VA_BITS_ACTUAL); > > } else > > error(FATAL, "cannot determine > > VA_BITS_ACTUAL\n"); > > } > > But since that section of code above is gated by the existence of > "vabits_actual", > it would really be a guess, correct? (and the CRASHDEBUG(1) statement is > certainly > misleading) > > The wholesale changes that the aarch64 developers keep doing to their virtual > memory > layout has made the crash utility's arm64.c a nightmare to maintain. And > patches like > the above (and below) only add to the confusion. Thanks, I agree with you. > > > > > > > > > > > > > > BTW, could you merge the patch which I posted today > > > > in case the '-device vmcoreinfo' isn't set to qemu? > > > > https://www.redhat.com/archives/crash-utility/2020-January/msg00010.html > > > > > > Honestly, I'm leaning against doing it, especially since the other two > > > issues that you referenced (VA_BITS and KASLR) would still exist without > > > "-device vmcoreinfo". > > > > > > I'd prefer not to put in a bunch of patches for problems that would only > > > exist > > > because a user has not properly configured QEMU. The whole point of the > > > vmcoreinfo device is specifically for its use by the crash utility. > > > > I think the patch is useful for old qemu/libvirt/kernel like as > > RHEL8 in case the libvirt/qemu doesn't have the vmcoreinfo option and > > the kernel doesn't have the VA_BITS issue... > > The RHEL8 kernel has the vmcoreinfo device since it's been upstream > since 4.17. Are you saying that the RHEL8 userspace component does > not support it? I thought I read somewhere that it went into libvirt 4.4, > and it looks like RHEL8's libvirt is based upon 4.5.0. You are right, the libivirt/qemu supports the feature. I'm sorry about my misunderstanding. So, I agree with you, we should use the vmcoreinfo option. Thanks! Masa > > Dave > > > > > - Masa > > > > > > > > Comments? > > > > > > Dave > > > > > > > > > > > > > Thanks, > > > > Masa > > > > > > > > > > > > > > Anyway, Daisuke should be able fill in the details. > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > - Masa > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > > > > > > ... > > > > > > > > > vmcore_data: > > > > > > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > > > > > > >ndfd: 3 > > > > > > > > > ofp: a5e81588 > > > > > > > > > header_size: 30896 > > > > > > > > >num_pt_load_segments: 1 > > > > > > > > > pt_load_segment[0]: > > > > > > > > > file_offset: 78b0 > > > > > > > > > phys_start: 4000 > > > > > > > > >phys_end: 26000 >
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
- Original Message - > On Mon, Jan 27, 2020 at 12:15:48PM -0500, Dave Anderson wrote: > > > > > > - Original Message - > > ... > > > > > > Thanks, I didn't know qemu has '-device vmcoreinfo' option. > > > > > > It seems that the vmcoreinfo option works for aarch64 as well. > > > The KASLR issue and the modules_vaddr issue are gone with > > > vmcoreinfo option. Great! > > > > > > However, VA_BITS issue still remains the vmcoreinfo doesn't have > > > 'NUMBER(tcr_el1_t1sz)'. > > > I suppose we can use 'NUMBER(VA_BITS)' instead, so I'll post another > > > patch later. > > > > Right -- Bhupesh is still working on getting NUMBER(tcr_el1_t1sz) accepted > > upstream. > > Great! > So, should we wait Bhupesh's patch is merged to upstream? > Or, is useful following workaround patch until then? > > diff --git a/arm64.c b/arm64.c > index 7662d71..bf93404 100644 > --- a/arm64.c > +++ b/arm64.c > @@ -3889,6 +3889,14 @@ arm64_calc_VA_BITS(void) > machdep->machspec->VA_BITS_ACTUAL = value; > machdep->machspec->VA_BITS = value; > machdep->machspec->VA_START = > _VA_START(machdep->machspec->VA_BITS_ACTUAL); > + } else if ((string = > pc->read_vmcoreinfo("NUMBER(VA_BITS)"))) { > + value = strtoll(string, NULL, 0); > + if (CRASHDEBUG(1)) > + fprintf(fp, "vmcoreinfo : > vabits_actual: %ld\n", value); > + free(string); > + machdep->machspec->VA_BITS_ACTUAL = value; > + machdep->machspec->VA_BITS = value; > + machdep->machspec->VA_START = > _VA_START(machdep->machspec->VA_BITS_ACTUAL); > } else > error(FATAL, "cannot determine > VA_BITS_ACTUAL\n"); > } But since that section of code above is gated by the existence of "vabits_actual", it would really be a guess, correct? (and the CRASHDEBUG(1) statement is certainly misleading) The wholesale changes that the aarch64 developers keep doing to their virtual memory layout has made the crash utility's arm64.c a nightmare to maintain. And patches like the above (and below) only add to the confusion. > > > > > > > > > BTW, could you merge the patch which I posted today > > > in case the '-device vmcoreinfo' isn't set to qemu? > > > https://www.redhat.com/archives/crash-utility/2020-January/msg00010.html > > > > Honestly, I'm leaning against doing it, especially since the other two > > issues that you referenced (VA_BITS and KASLR) would still exist without > > "-device vmcoreinfo". > > > > I'd prefer not to put in a bunch of patches for problems that would only > > exist > > because a user has not properly configured QEMU. The whole point of the > > vmcoreinfo device is specifically for its use by the crash utility. > > I think the patch is useful for old qemu/libvirt/kernel like as > RHEL8 in case the libvirt/qemu doesn't have the vmcoreinfo option and > the kernel doesn't have the VA_BITS issue... The RHEL8 kernel has the vmcoreinfo device since it's been upstream since 4.17. Are you saying that the RHEL8 userspace component does not support it? I thought I read somewhere that it went into libvirt 4.4, and it looks like RHEL8's libvirt is based upon 4.5.0. Dave > > - Masa > > > > > Comments? > > > > Dave > > > > > > > > > Thanks, > > > Masa > > > > > > > > > > > Anyway, Daisuke should be able fill in the details. > > > > > > > > Dave > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > - Masa > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > > > > > ... > > > > > > > > vmcore_data: > > > > > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > > > > > >ndfd: 3 > > > > > > > > ofp: a5e81588 > > > > > > > > header_size: 30896 > > > > > > > >num_pt_load_segments: 1 > > > > > > > > pt_load_segment[0]: > > > > > > > > file_offset: 78b0 > > > > > > > > phys_start: 4000 > > > > > > > >phys_end: 26000 > > > > > > > > zero_fill: 0 > > > > > > > > elf_header: 2ed6d4e0 > > > > > > > > elf32: 0 > > > > > > > > notes32: 0 > > > > > > > > load32: 0 > > > > > > > > elf64: 2ed6d4e0 > > > > > > > > notes64: 2ed6d520 > > > > > > > > load64: 2ed6d558 > > > > > > > >sect0_64: 0 > > > > > > > > nt_prstatus: 2ed6d590 > > > > > > > > nt_prpsinfo: 0 > > > > > > > >
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
On Mon, Jan 27, 2020 at 12:15:48PM -0500, Dave Anderson wrote: > > > - Original Message - > ... > > > > Thanks, I didn't know qemu has '-device vmcoreinfo' option. > > > > It seems that the vmcoreinfo option works for aarch64 as well. > > The KASLR issue and the modules_vaddr issue are gone with > > vmcoreinfo option. Great! > > > > However, VA_BITS issue still remains the vmcoreinfo doesn't have > > 'NUMBER(tcr_el1_t1sz)'. > > I suppose we can use 'NUMBER(VA_BITS)' instead, so I'll post > > another patch later. > > Right -- Bhupesh is still working on getting NUMBER(tcr_el1_t1sz) > accepted upstream. Great! So, should we wait Bhupesh's patch is merged to upstream? Or, is useful following workaround patch until then? diff --git a/arm64.c b/arm64.c index 7662d71..bf93404 100644 --- a/arm64.c +++ b/arm64.c @@ -3889,6 +3889,14 @@ arm64_calc_VA_BITS(void) machdep->machspec->VA_BITS_ACTUAL = value; machdep->machspec->VA_BITS = value; machdep->machspec->VA_START = _VA_START(machdep->machspec->VA_BITS_ACTUAL); + } else if ((string = pc->read_vmcoreinfo("NUMBER(VA_BITS)"))) { + value = strtoll(string, NULL, 0); + if (CRASHDEBUG(1)) + fprintf(fp, "vmcoreinfo : vabits_actual: %ld\n", value); + free(string); + machdep->machspec->VA_BITS_ACTUAL = value; + machdep->machspec->VA_BITS = value; + machdep->machspec->VA_START = _VA_START(machdep->machspec->VA_BITS_ACTUAL); } else error(FATAL, "cannot determine VA_BITS_ACTUAL\n"); } > > > > > BTW, could you merge the patch which I posted today > > in case the '-device vmcoreinfo' isn't set to qemu? > > https://www.redhat.com/archives/crash-utility/2020-January/msg00010.html > > Honestly, I'm leaning against doing it, especially since the other two > issues that you referenced (VA_BITS and KASLR) would still exist without > "-device vmcoreinfo". > > I'd prefer not to put in a bunch of patches for problems that would only exist > because a user has not properly configured QEMU. The whole point of the > vmcoreinfo device is specifically for its use by the crash utility. I think the patch is useful for old qemu/libvirt/kernel like as RHEL8 in case the libvirt/qemu doesn't have the vmcoreinfo option and the kernel doesn't have the VA_BITS issue... - Masa > > Comments? > > Dave > > > > > Thanks, > > Masa > > > > > > > > Anyway, Daisuke should be able fill in the details. > > > > > > Dave > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > - Masa > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > > > > ... > > > > > > > vmcore_data: > > > > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > > > > >ndfd: 3 > > > > > > > ofp: a5e81588 > > > > > > > header_size: 30896 > > > > > > >num_pt_load_segments: 1 > > > > > > > pt_load_segment[0]: > > > > > > > file_offset: 78b0 > > > > > > > phys_start: 4000 > > > > > > >phys_end: 26000 > > > > > > > zero_fill: 0 > > > > > > > elf_header: 2ed6d4e0 > > > > > > > elf32: 0 > > > > > > > notes32: 0 > > > > > > > load32: 0 > > > > > > > elf64: 2ed6d4e0 > > > > > > > notes64: 2ed6d520 > > > > > > > load64: 2ed6d558 > > > > > > >sect0_64: 0 > > > > > > > nt_prstatus: 2ed6d590 > > > > > > > nt_prpsinfo: 0 > > > > > > > nt_taskstruct: 0 > > > > > > > task_struct: 0 > > > > > > > arch_data1: (unused) > > > > > > > arch_data2: (unused) > > > > > > >switch_stack: 0 > > > > > > > page_size: 0 > > > > > > > xen_kdump_data: (unused) > > > > > > > num_prstatus_notes: 32 > > > > > > > num_qemu_notes: 0 > > > > > > > vmcoreinfo: 0 > > > > > > > size_vmcoreinfo: 0 > > > > > > > nt_prstatus_percpu: > > > > > > > 2ed6d590 2ed6d950 2ed6dd10 > > > > > > > 2ed6e0d0 > > > > > > > 2ed6e490 2ed6e850 2ed6ec10 > > > > > > > 2ed6efd0 > > > > > > > 2ed6f390 2ed6f750 2ed6fb10 > > > > > > > 2ed6fed0 > > > > > > > 2ed70290 2ed70650 2ed70a10 > > > > > > > 2ed70dd0 > > > > > > > 2ed71190
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
- Original Message - ... > > Thanks, I didn't know qemu has '-device vmcoreinfo' option. > > It seems that the vmcoreinfo option works for aarch64 as well. > The KASLR issue and the modules_vaddr issue are gone with > vmcoreinfo option. Great! > > However, VA_BITS issue still remains the vmcoreinfo doesn't have > 'NUMBER(tcr_el1_t1sz)'. > I suppose we can use 'NUMBER(VA_BITS)' instead, so I'll post > another patch later. Right -- Bhupesh is still working on getting NUMBER(tcr_el1_t1sz) accepted upstream. > > BTW, could you merge the patch which I posted today > in case the '-device vmcoreinfo' isn't set to qemu? > https://www.redhat.com/archives/crash-utility/2020-January/msg00010.html Honestly, I'm leaning against doing it, especially since the other two issues that you referenced (VA_BITS and KASLR) would still exist without "-device vmcoreinfo". I'd prefer not to put in a bunch of patches for problems that would only exist because a user has not properly configured QEMU. The whole point of the vmcoreinfo device is specifically for its use by the crash utility. Comments? Dave > Thanks, > Masa > > > > > Anyway, Daisuke should be able fill in the details. > > > > Dave > > > > > > > > > > Dave > > > > > > > > > > > > > > - Masa > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > > > ... > > > > > > vmcore_data: > > > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > > > >ndfd: 3 > > > > > > ofp: a5e81588 > > > > > > header_size: 30896 > > > > > >num_pt_load_segments: 1 > > > > > > pt_load_segment[0]: > > > > > > file_offset: 78b0 > > > > > > phys_start: 4000 > > > > > >phys_end: 26000 > > > > > > zero_fill: 0 > > > > > > elf_header: 2ed6d4e0 > > > > > > elf32: 0 > > > > > > notes32: 0 > > > > > > load32: 0 > > > > > > elf64: 2ed6d4e0 > > > > > > notes64: 2ed6d520 > > > > > > load64: 2ed6d558 > > > > > >sect0_64: 0 > > > > > > nt_prstatus: 2ed6d590 > > > > > > nt_prpsinfo: 0 > > > > > > nt_taskstruct: 0 > > > > > > task_struct: 0 > > > > > > arch_data1: (unused) > > > > > > arch_data2: (unused) > > > > > >switch_stack: 0 > > > > > > page_size: 0 > > > > > > xen_kdump_data: (unused) > > > > > > num_prstatus_notes: 32 > > > > > > num_qemu_notes: 0 > > > > > > vmcoreinfo: 0 > > > > > > size_vmcoreinfo: 0 > > > > > > nt_prstatus_percpu: > > > > > > 2ed6d590 2ed6d950 2ed6dd10 > > > > > > 2ed6e0d0 > > > > > > 2ed6e490 2ed6e850 2ed6ec10 > > > > > > 2ed6efd0 > > > > > > 2ed6f390 2ed6f750 2ed6fb10 > > > > > > 2ed6fed0 > > > > > > 2ed70290 2ed70650 2ed70a10 > > > > > > 2ed70dd0 > > > > > > 2ed71190 2ed71550 2ed71910 > > > > > > 2ed71cd0 > > > > > > 2ed72090 2ed72450 2ed72810 > > > > > > 2ed72bd0 > > > > > > 2ed72f90 2ed73350 2ed73710 > > > > > > 2ed73ad0 > > > > > > 2ed73e90 2ed74250 2ed74610 > > > > > > 2ed749d0 > > > > > > nt_qemu_percpu: > > > > > >backup_src_start: 0 > > > > > > backup_src_size: 0 > > > > > > backup_offset: 0 > > > > > > ... > > > > > > > > > > > > Thanks, > > > > > > Masa > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > 1. KASLR > > > > > > > >crash doesn't work in case KASLR is enabled on the guest. > > > > > > > >That is because the memory dump doesn't have vmcoreinfo, so > > > > > > > >we > > > > > > > >cannot get the relocation position. > > > > > > > >I suppose we need to implement calc_kaslr_offset() for > > > > > > > >aarch64. > > > > > > > >nokaslr with the guest kernel parameter is a workaround. > > > > > > > > > > > > > > > > 2. VA_BITS > > > > > > > >crash doesn't work in case the guest kernel is v5.4 and > > > > > > > >later. > > > > > > > >That is because the memory dump doesn't have vmcoreinfo, so > > > > > > > >we > > > > > > > >cannot get vabits_actual. > > > > > > > >I think there's no workaround so far... > > > > > > > > > > > > > > > > Masayoshi Mizuma (1): > > > > > > > > arm64: Fix missing offset for modules_vaddr with aarch64 > > > > > > > > guest > > > > > > > > dump > > > > > > > > > > > > > > > > arm64.c |
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
On Mon, Jan 27, 2020 at 11:04:44AM -0500, Dave Anderson wrote: > > > - Original Message - > > > > > > - Original Message - > > > On Mon, Jan 27, 2020 at 10:17:51AM -0500, Dave Anderson wrote: > > > > > > > > > > > > - Original Message - > > > > > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: Masayoshi Mizuma > > > > > > > > > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > > > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > > > > > BPF JIT programs in module memory") and the memory dump > > > > > > > is captured by virsh dump. > > > > > > > > > > > > > > Note: Another two issues remain for the memory dump captured by > > > > > > > virsh dump with aarch64. > > > > > > > > > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > > > > > for the virsh dump for quite some time now. Is it not passed back > > > > > > to the host on aarch64? > > > > > > > > > > The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo > > > > > isn't captured by virsh dump. > > > > > Am I missing something...? > > > > > > > > I'm not sure -- are you using "virsh dump --memory-only ..."? > > > > > > Yes, I'm using --memory-only option like as: > > > > > > virsh dump --crash --memory-only > > > > OK, then that's news to me. We went through this a while ago on x86_64 > > because it required the vmcoreinfo "phys_base". It took awhile to get > > it upstream, but now the whole vmcoreinfo note is passed for virsh dump > > to include with the dumpfile. Maybe it's x86_64 only? > > Looking back through old bugzillas, google, etc, it does seem to indicate > that the support covers "arm/x86", which I presume covers aarch64. See > kernel commit 2d6d60a3d3eca50bbb20052278cb11dabcf4dff3 titled > "fw_cfg: write vmcoreinfo details". > > I see a few old postings from Daisuke that indicate the the vmcoreinfo device > has be registered with a "devices" or "features" file on the host (?) by > using "virsh edit"? Again, sorry, I'm clueless. Thanks, I didn't know qemu has '-device vmcoreinfo' option. It seems that the vmcoreinfo option works for aarch64 as well. The KASLR issue and the modules_vaddr issue are gone with vmcoreinfo option. Great! However, VA_BITS issue still remains the vmcoreinfo doesn't have 'NUMBER(tcr_el1_t1sz)'. I suppose we can use 'NUMBER(VA_BITS)' instead, so I'll post another patch later. BTW, could you merge the patch which I posted today in case the '-device vmcoreinfo' isn't set to qemu? https://www.redhat.com/archives/crash-utility/2020-January/msg00010.html Thanks, Masa > > Anyway, Daisuke should be able fill in the details. > > Dave > > > > > > Dave > > > > > > > > > > - Masa > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > > ... > > > > > vmcore_data: > > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > > >ndfd: 3 > > > > > ofp: a5e81588 > > > > > header_size: 30896 > > > > >num_pt_load_segments: 1 > > > > > pt_load_segment[0]: > > > > > file_offset: 78b0 > > > > > phys_start: 4000 > > > > >phys_end: 26000 > > > > > zero_fill: 0 > > > > > elf_header: 2ed6d4e0 > > > > > elf32: 0 > > > > > notes32: 0 > > > > > load32: 0 > > > > > elf64: 2ed6d4e0 > > > > > notes64: 2ed6d520 > > > > > load64: 2ed6d558 > > > > >sect0_64: 0 > > > > > nt_prstatus: 2ed6d590 > > > > > nt_prpsinfo: 0 > > > > > nt_taskstruct: 0 > > > > > task_struct: 0 > > > > > arch_data1: (unused) > > > > > arch_data2: (unused) > > > > >switch_stack: 0 > > > > > page_size: 0 > > > > > xen_kdump_data: (unused) > > > > > num_prstatus_notes: 32 > > > > > num_qemu_notes: 0 > > > > > vmcoreinfo: 0 > > > > > size_vmcoreinfo: 0 > > > > > nt_prstatus_percpu: > > > > > 2ed6d590 2ed6d950 2ed6dd10 > > > > > 2ed6e0d0 > > > > > 2ed6e490 2ed6e850 2ed6ec10 > > > > > 2ed6efd0 > > > > > 2ed6f390 2ed6f750 2ed6fb10 > > > > > 2ed6fed0 > > > > > 2ed70290 2ed70650 2ed70a10 > > > > > 2ed70dd0 > > > > > 2ed71190 2ed71550 2ed71910 > > > > > 2ed71cd0 > > > > > 2ed72090 2ed72450 2ed72810 > > > > > 2ed72bd0 > > > > > 2ed72f90 2ed73350 2ed73710 > > > > >
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
Masa, Check https://libvirt.org/formatdomain.html#elementsFeatures and grep for "vmcoreinfo". It would seem like "vmcoreinfo state" would be "on" by default, but I'm not sure. Dave - Original Message - > > > - Original Message - > > > > > > - Original Message - > > > On Mon, Jan 27, 2020 at 10:17:51AM -0500, Dave Anderson wrote: > > > > > > > > > > > > - Original Message - > > > > > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: Masayoshi Mizuma > > > > > > > > > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > > > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > > > > > BPF JIT programs in module memory") and the memory dump > > > > > > > is captured by virsh dump. > > > > > > > > > > > > > > Note: Another two issues remain for the memory dump captured by > > > > > > > virsh dump with aarch64. > > > > > > > > > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > > > > > for the virsh dump for quite some time now. Is it not passed back > > > > > > to the host on aarch64? > > > > > > > > > > The vmcore_data shows that vmcoreinfo size is 0, so I think > > > > > vmcoreinfo > > > > > isn't captured by virsh dump. > > > > > Am I missing something...? > > > > > > > > I'm not sure -- are you using "virsh dump --memory-only ..."? > > > > > > Yes, I'm using --memory-only option like as: > > > > > > virsh dump --crash --memory-only > > > > OK, then that's news to me. We went through this a while ago on x86_64 > > because it required the vmcoreinfo "phys_base". It took awhile to get > > it upstream, but now the whole vmcoreinfo note is passed for virsh dump > > to include with the dumpfile. Maybe it's x86_64 only? > > Looking back through old bugzillas, google, etc, it does seem to indicate > that the support covers "arm/x86", which I presume covers aarch64. See > kernel commit 2d6d60a3d3eca50bbb20052278cb11dabcf4dff3 titled > "fw_cfg: write vmcoreinfo details". > > I see a few old postings from Daisuke that indicate the the vmcoreinfo device > has be registered with a "devices" or "features" file on the host (?) by > using "virsh edit"? Again, sorry, I'm clueless. > > Anyway, Daisuke should be able fill in the details. > > Dave > > > > > > Dave > > > > > > > > > > - Masa > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > > ... > > > > > vmcore_data: > > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > > >ndfd: 3 > > > > > ofp: a5e81588 > > > > > header_size: 30896 > > > > >num_pt_load_segments: 1 > > > > > pt_load_segment[0]: > > > > > file_offset: 78b0 > > > > > phys_start: 4000 > > > > >phys_end: 26000 > > > > > zero_fill: 0 > > > > > elf_header: 2ed6d4e0 > > > > > elf32: 0 > > > > > notes32: 0 > > > > > load32: 0 > > > > > elf64: 2ed6d4e0 > > > > > notes64: 2ed6d520 > > > > > load64: 2ed6d558 > > > > >sect0_64: 0 > > > > > nt_prstatus: 2ed6d590 > > > > > nt_prpsinfo: 0 > > > > > nt_taskstruct: 0 > > > > > task_struct: 0 > > > > > arch_data1: (unused) > > > > > arch_data2: (unused) > > > > >switch_stack: 0 > > > > > page_size: 0 > > > > > xen_kdump_data: (unused) > > > > > num_prstatus_notes: 32 > > > > > num_qemu_notes: 0 > > > > > vmcoreinfo: 0 > > > > > size_vmcoreinfo: 0 > > > > > nt_prstatus_percpu: > > > > > 2ed6d590 2ed6d950 2ed6dd10 > > > > > 2ed6e0d0 > > > > > 2ed6e490 2ed6e850 2ed6ec10 > > > > > 2ed6efd0 > > > > > 2ed6f390 2ed6f750 2ed6fb10 > > > > > 2ed6fed0 > > > > > 2ed70290 2ed70650 2ed70a10 > > > > > 2ed70dd0 > > > > > 2ed71190 2ed71550 2ed71910 > > > > > 2ed71cd0 > > > > > 2ed72090 2ed72450 2ed72810 > > > > > 2ed72bd0 > > > > > 2ed72f90 2ed73350 2ed73710 > > > > > 2ed73ad0 > > > > > 2ed73e90 2ed74250 2ed74610 > > > > > 2ed749d0 > > > > > nt_qemu_percpu: > > > > >backup_src_start: 0 > > > > > backup_src_size: 0 > > > > > backup_offset: 0 > > > > > ... > > > > > > > > > > Thanks, > > > > > Masa > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > I > > > > >
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
- Original Message - > > > - Original Message - > > On Mon, Jan 27, 2020 at 10:17:51AM -0500, Dave Anderson wrote: > > > > > > > > > - Original Message - > > > > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > > > > > > > > > > - Original Message - > > > > > > From: Masayoshi Mizuma > > > > > > > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > > > > BPF JIT programs in module memory") and the memory dump > > > > > > is captured by virsh dump. > > > > > > > > > > > > Note: Another two issues remain for the memory dump captured by > > > > > > virsh dump with aarch64. > > > > > > > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > > > > for the virsh dump for quite some time now. Is it not passed back > > > > > to the host on aarch64? > > > > > > > > The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo > > > > isn't captured by virsh dump. > > > > Am I missing something...? > > > > > > I'm not sure -- are you using "virsh dump --memory-only ..."? > > > > Yes, I'm using --memory-only option like as: > > > > virsh dump --crash --memory-only > > OK, then that's news to me. We went through this a while ago on x86_64 > because it required the vmcoreinfo "phys_base". It took awhile to get > it upstream, but now the whole vmcoreinfo note is passed for virsh dump > to include with the dumpfile. Maybe it's x86_64 only? Looking back through old bugzillas, google, etc, it does seem to indicate that the support covers "arm/x86", which I presume covers aarch64. See kernel commit 2d6d60a3d3eca50bbb20052278cb11dabcf4dff3 titled "fw_cfg: write vmcoreinfo details". I see a few old postings from Daisuke that indicate the the vmcoreinfo device has be registered with a "devices" or "features" file on the host (?) by using "virsh edit"? Again, sorry, I'm clueless. Anyway, Daisuke should be able fill in the details. Dave > > Dave > > > > > > - Masa > > > > > > > > Dave > > > > > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > > ... > > > > vmcore_data: > > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > > >ndfd: 3 > > > > ofp: a5e81588 > > > > header_size: 30896 > > > >num_pt_load_segments: 1 > > > > pt_load_segment[0]: > > > > file_offset: 78b0 > > > > phys_start: 4000 > > > >phys_end: 26000 > > > > zero_fill: 0 > > > > elf_header: 2ed6d4e0 > > > > elf32: 0 > > > > notes32: 0 > > > > load32: 0 > > > > elf64: 2ed6d4e0 > > > > notes64: 2ed6d520 > > > > load64: 2ed6d558 > > > >sect0_64: 0 > > > > nt_prstatus: 2ed6d590 > > > > nt_prpsinfo: 0 > > > > nt_taskstruct: 0 > > > > task_struct: 0 > > > > arch_data1: (unused) > > > > arch_data2: (unused) > > > >switch_stack: 0 > > > > page_size: 0 > > > > xen_kdump_data: (unused) > > > > num_prstatus_notes: 32 > > > > num_qemu_notes: 0 > > > > vmcoreinfo: 0 > > > > size_vmcoreinfo: 0 > > > > nt_prstatus_percpu: > > > > 2ed6d590 2ed6d950 2ed6dd10 > > > > 2ed6e0d0 > > > > 2ed6e490 2ed6e850 2ed6ec10 > > > > 2ed6efd0 > > > > 2ed6f390 2ed6f750 2ed6fb10 > > > > 2ed6fed0 > > > > 2ed70290 2ed70650 2ed70a10 > > > > 2ed70dd0 > > > > 2ed71190 2ed71550 2ed71910 > > > > 2ed71cd0 > > > > 2ed72090 2ed72450 2ed72810 > > > > 2ed72bd0 > > > > 2ed72f90 2ed73350 2ed73710 > > > > 2ed73ad0 > > > > 2ed73e90 2ed74250 2ed74610 > > > > 2ed749d0 > > > > nt_qemu_percpu: > > > >backup_src_start: 0 > > > > backup_src_size: 0 > > > > backup_offset: 0 > > > > ... > > > > > > > > Thanks, > > > > Masa > > > > > > > > > > > > > > Dave > > > > > > > > > > I > > > > > > > > > > > > 1. KASLR > > > > > >crash doesn't work in case KASLR is enabled on the guest. > > > > > >That is because the memory dump doesn't have vmcoreinfo, so we > > > > > >cannot get the relocation position. > > > > > >I suppose we need to implement calc_kaslr_offset() for aarch64. > > > > > >nokaslr with the guest kernel parameter is a workaround. > > > > > > > > > > > > 2. VA_BITS > > > > > >crash doesn't work in case the guest kernel is v5.4 and
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
- Original Message - > On Mon, Jan 27, 2020 at 10:17:51AM -0500, Dave Anderson wrote: > > > > > > - Original Message - > > > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > > > > > > > - Original Message - > > > > > From: Masayoshi Mizuma > > > > > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > > > BPF JIT programs in module memory") and the memory dump > > > > > is captured by virsh dump. > > > > > > > > > > Note: Another two issues remain for the memory dump captured by > > > > > virsh dump with aarch64. > > > > > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > > > for the virsh dump for quite some time now. Is it not passed back > > > > to the host on aarch64? > > > > > > The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo > > > isn't captured by virsh dump. > > > Am I missing something...? > > > > I'm not sure -- are you using "virsh dump --memory-only ..."? > > Yes, I'm using --memory-only option like as: > > virsh dump --crash --memory-only OK, then that's news to me. We went through this a while ago on x86_64 because it required the vmcoreinfo "phys_base". It took awhile to get it upstream, but now the whole vmcoreinfo note is passed for virsh dump to include with the dumpfile. Maybe it's x86_64 only? Dave > > - Masa > > > > > Dave > > > > > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > > ... > > > vmcore_data: > > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > > >ndfd: 3 > > > ofp: a5e81588 > > > header_size: 30896 > > >num_pt_load_segments: 1 > > > pt_load_segment[0]: > > > file_offset: 78b0 > > > phys_start: 4000 > > >phys_end: 26000 > > > zero_fill: 0 > > > elf_header: 2ed6d4e0 > > > elf32: 0 > > > notes32: 0 > > > load32: 0 > > > elf64: 2ed6d4e0 > > > notes64: 2ed6d520 > > > load64: 2ed6d558 > > >sect0_64: 0 > > > nt_prstatus: 2ed6d590 > > > nt_prpsinfo: 0 > > > nt_taskstruct: 0 > > > task_struct: 0 > > > arch_data1: (unused) > > > arch_data2: (unused) > > >switch_stack: 0 > > > page_size: 0 > > > xen_kdump_data: (unused) > > > num_prstatus_notes: 32 > > > num_qemu_notes: 0 > > > vmcoreinfo: 0 > > > size_vmcoreinfo: 0 > > > nt_prstatus_percpu: > > > 2ed6d590 2ed6d950 2ed6dd10 > > > 2ed6e0d0 > > > 2ed6e490 2ed6e850 2ed6ec10 > > > 2ed6efd0 > > > 2ed6f390 2ed6f750 2ed6fb10 > > > 2ed6fed0 > > > 2ed70290 2ed70650 2ed70a10 > > > 2ed70dd0 > > > 2ed71190 2ed71550 2ed71910 > > > 2ed71cd0 > > > 2ed72090 2ed72450 2ed72810 > > > 2ed72bd0 > > > 2ed72f90 2ed73350 2ed73710 > > > 2ed73ad0 > > > 2ed73e90 2ed74250 2ed74610 > > > 2ed749d0 > > > nt_qemu_percpu: > > >backup_src_start: 0 > > > backup_src_size: 0 > > > backup_offset: 0 > > > ... > > > > > > Thanks, > > > Masa > > > > > > > > > > > Dave > > > > > > > > I > > > > > > > > > > 1. KASLR > > > > >crash doesn't work in case KASLR is enabled on the guest. > > > > >That is because the memory dump doesn't have vmcoreinfo, so we > > > > >cannot get the relocation position. > > > > >I suppose we need to implement calc_kaslr_offset() for aarch64. > > > > >nokaslr with the guest kernel parameter is a workaround. > > > > > > > > > > 2. VA_BITS > > > > >crash doesn't work in case the guest kernel is v5.4 and later. > > > > >That is because the memory dump doesn't have vmcoreinfo, so we > > > > >cannot get vabits_actual. > > > > >I think there's no workaround so far... > > > > > > > > > > Masayoshi Mizuma (1): > > > > > arm64: Fix missing offset for modules_vaddr with aarch64 guest dump > > > > > > > > > > arm64.c | 2 ++ > > > > > defs.h | 3 +++ > > > > > 2 files changed, 5 insertions(+) > > > > > > > > > > -- > > > > > 2.18.1 > > > > > > > > > > > > > > > -- > > > > > Crash-utility mailing list > > > > > Crash-utility@redhat.com > > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > > > > > > > -- > > > > Crash-utility mailing list > > > > Crash-utility@redhat.com > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > >
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
On Mon, Jan 27, 2020 at 10:17:51AM -0500, Dave Anderson wrote: > > > - Original Message - > > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > > > > - Original Message - > > > > From: Masayoshi Mizuma > > > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > > BPF JIT programs in module memory") and the memory dump > > > > is captured by virsh dump. > > > > > > > > Note: Another two issues remain for the memory dump captured by > > > > virsh dump with aarch64. > > > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > > for the virsh dump for quite some time now. Is it not passed back > > > to the host on aarch64? > > > > The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo > > isn't captured by virsh dump. > > Am I missing something...? > > I'm not sure -- are you using "virsh dump --memory-only ..."? Yes, I'm using --memory-only option like as: virsh dump --crash --memory-only - Masa > > Dave > > > > > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > > ... > > vmcore_data: > > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) > >ndfd: 3 > > ofp: a5e81588 > > header_size: 30896 > >num_pt_load_segments: 1 > > pt_load_segment[0]: > > file_offset: 78b0 > > phys_start: 4000 > >phys_end: 26000 > > zero_fill: 0 > > elf_header: 2ed6d4e0 > > elf32: 0 > > notes32: 0 > > load32: 0 > > elf64: 2ed6d4e0 > > notes64: 2ed6d520 > > load64: 2ed6d558 > >sect0_64: 0 > > nt_prstatus: 2ed6d590 > > nt_prpsinfo: 0 > > nt_taskstruct: 0 > > task_struct: 0 > > arch_data1: (unused) > > arch_data2: (unused) > >switch_stack: 0 > > page_size: 0 > > xen_kdump_data: (unused) > > num_prstatus_notes: 32 > > num_qemu_notes: 0 > > vmcoreinfo: 0 > > size_vmcoreinfo: 0 > > nt_prstatus_percpu: > > 2ed6d590 2ed6d950 2ed6dd10 2ed6e0d0 > > 2ed6e490 2ed6e850 2ed6ec10 2ed6efd0 > > 2ed6f390 2ed6f750 2ed6fb10 2ed6fed0 > > 2ed70290 2ed70650 2ed70a10 2ed70dd0 > > 2ed71190 2ed71550 2ed71910 2ed71cd0 > > 2ed72090 2ed72450 2ed72810 2ed72bd0 > > 2ed72f90 2ed73350 2ed73710 2ed73ad0 > > 2ed73e90 2ed74250 2ed74610 2ed749d0 > > nt_qemu_percpu: > >backup_src_start: 0 > > backup_src_size: 0 > > backup_offset: 0 > > ... > > > > Thanks, > > Masa > > > > > > > > Dave > > > > > > I > > > > > > > > 1. KASLR > > > >crash doesn't work in case KASLR is enabled on the guest. > > > >That is because the memory dump doesn't have vmcoreinfo, so we > > > >cannot get the relocation position. > > > >I suppose we need to implement calc_kaslr_offset() for aarch64. > > > >nokaslr with the guest kernel parameter is a workaround. > > > > > > > > 2. VA_BITS > > > >crash doesn't work in case the guest kernel is v5.4 and later. > > > >That is because the memory dump doesn't have vmcoreinfo, so we > > > >cannot get vabits_actual. > > > >I think there's no workaround so far... > > > > > > > > Masayoshi Mizuma (1): > > > > arm64: Fix missing offset for modules_vaddr with aarch64 guest dump > > > > > > > > arm64.c | 2 ++ > > > > defs.h | 3 +++ > > > > 2 files changed, 5 insertions(+) > > > > > > > > -- > > > > 2.18.1 > > > > > > > > > > > > -- > > > > Crash-utility mailing list > > > > Crash-utility@redhat.com > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > > > > -- > > > Crash-utility mailing list > > > Crash-utility@redhat.com > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
- Original Message - > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > - Original Message - > > > From: Masayoshi Mizuma > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > BPF JIT programs in module memory") and the memory dump > > > is captured by virsh dump. > > > > > > Note: Another two issues remain for the memory dump captured by > > > virsh dump with aarch64. > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > for the virsh dump for quite some time now. Is it not passed back > > to the host on aarch64? > > The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo > isn't captured by virsh dump. > Am I missing something...? I'm not sure -- are you using "virsh dump --memory-only ..."? Dave > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > ... > vmcore_data: > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) >ndfd: 3 > ofp: a5e81588 > header_size: 30896 >num_pt_load_segments: 1 > pt_load_segment[0]: > file_offset: 78b0 > phys_start: 4000 >phys_end: 26000 > zero_fill: 0 > elf_header: 2ed6d4e0 > elf32: 0 > notes32: 0 > load32: 0 > elf64: 2ed6d4e0 > notes64: 2ed6d520 > load64: 2ed6d558 >sect0_64: 0 > nt_prstatus: 2ed6d590 > nt_prpsinfo: 0 > nt_taskstruct: 0 > task_struct: 0 > arch_data1: (unused) > arch_data2: (unused) >switch_stack: 0 > page_size: 0 > xen_kdump_data: (unused) > num_prstatus_notes: 32 > num_qemu_notes: 0 > vmcoreinfo: 0 > size_vmcoreinfo: 0 > nt_prstatus_percpu: > 2ed6d590 2ed6d950 2ed6dd10 2ed6e0d0 > 2ed6e490 2ed6e850 2ed6ec10 2ed6efd0 > 2ed6f390 2ed6f750 2ed6fb10 2ed6fed0 > 2ed70290 2ed70650 2ed70a10 2ed70dd0 > 2ed71190 2ed71550 2ed71910 2ed71cd0 > 2ed72090 2ed72450 2ed72810 2ed72bd0 > 2ed72f90 2ed73350 2ed73710 2ed73ad0 > 2ed73e90 2ed74250 2ed74610 2ed749d0 > nt_qemu_percpu: >backup_src_start: 0 > backup_src_size: 0 > backup_offset: 0 > ... > > Thanks, > Masa > > > > > Dave > > > > I > > > > > > 1. KASLR > > >crash doesn't work in case KASLR is enabled on the guest. > > >That is because the memory dump doesn't have vmcoreinfo, so we > > >cannot get the relocation position. > > >I suppose we need to implement calc_kaslr_offset() for aarch64. > > >nokaslr with the guest kernel parameter is a workaround. > > > > > > 2. VA_BITS > > >crash doesn't work in case the guest kernel is v5.4 and later. > > >That is because the memory dump doesn't have vmcoreinfo, so we > > >cannot get vabits_actual. > > >I think there's no workaround so far... > > > > > > Masayoshi Mizuma (1): > > > arm64: Fix missing offset for modules_vaddr with aarch64 guest dump > > > > > > arm64.c | 2 ++ > > > defs.h | 3 +++ > > > 2 files changed, 5 insertions(+) > > > > > > -- > > > 2.18.1 > > > > > > > > > -- > > > Crash-utility mailing list > > > Crash-utility@redhat.com > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > -- > > Crash-utility mailing list > > Crash-utility@redhat.com > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
On Mon, Jan 27, 2020 at 10:06:57AM -0500, Masayoshi Mizuma wrote: > On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > > > > - Original Message - > > > From: Masayoshi Mizuma > > > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > > BPF JIT programs in module memory") and the memory dump > > > is captured by virsh dump. > > > > > > Note: Another two issues remain for the memory dump captured by > > > virsh dump with aarch64. > > > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > > for the virsh dump for quite some time now. Is it not passed back > > to the host on aarch64? > > The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo > isn't captured by virsh dump. > Am I missing something...? I captured the memory dump by: virsh dump --crash --memory-only - Masa > > ./crash -d1 vmlinux-v5.4 dump.v5.4 > ... > vmcore_data: > flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) >ndfd: 3 > ofp: a5e81588 > header_size: 30896 >num_pt_load_segments: 1 > pt_load_segment[0]: > file_offset: 78b0 > phys_start: 4000 >phys_end: 26000 > zero_fill: 0 > elf_header: 2ed6d4e0 > elf32: 0 > notes32: 0 > load32: 0 > elf64: 2ed6d4e0 > notes64: 2ed6d520 > load64: 2ed6d558 >sect0_64: 0 > nt_prstatus: 2ed6d590 > nt_prpsinfo: 0 > nt_taskstruct: 0 > task_struct: 0 > arch_data1: (unused) > arch_data2: (unused) >switch_stack: 0 > page_size: 0 > xen_kdump_data: (unused) > num_prstatus_notes: 32 > num_qemu_notes: 0 > vmcoreinfo: 0 > size_vmcoreinfo: 0 > nt_prstatus_percpu: > 2ed6d590 2ed6d950 2ed6dd10 2ed6e0d0 > 2ed6e490 2ed6e850 2ed6ec10 2ed6efd0 > 2ed6f390 2ed6f750 2ed6fb10 2ed6fed0 > 2ed70290 2ed70650 2ed70a10 2ed70dd0 > 2ed71190 2ed71550 2ed71910 2ed71cd0 > 2ed72090 2ed72450 2ed72810 2ed72bd0 > 2ed72f90 2ed73350 2ed73710 2ed73ad0 > 2ed73e90 2ed74250 2ed74610 2ed749d0 > nt_qemu_percpu: >backup_src_start: 0 > backup_src_size: 0 > backup_offset: 0 > ... > > Thanks, > Masa > > > > > Dave > > > > I > > > > > > 1. KASLR > > >crash doesn't work in case KASLR is enabled on the guest. > > >That is because the memory dump doesn't have vmcoreinfo, so we > > >cannot get the relocation position. > > >I suppose we need to implement calc_kaslr_offset() for aarch64. > > >nokaslr with the guest kernel parameter is a workaround. > > > > > > 2. VA_BITS > > >crash doesn't work in case the guest kernel is v5.4 and later. > > >That is because the memory dump doesn't have vmcoreinfo, so we > > >cannot get vabits_actual. > > >I think there's no workaround so far... > > > > > > Masayoshi Mizuma (1): > > > arm64: Fix missing offset for modules_vaddr with aarch64 guest dump > > > > > > arm64.c | 2 ++ > > > defs.h | 3 +++ > > > 2 files changed, 5 insertions(+) > > > > > > -- > > > 2.18.1 > > > > > > > > > -- > > > Crash-utility mailing list > > > Crash-utility@redhat.com > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > -- > > Crash-utility mailing list > > Crash-utility@redhat.com > > https://www.redhat.com/mailman/listinfo/crash-utility > > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote: > > > - Original Message - > > From: Masayoshi Mizuma > > > > Fix for aarch64 with Linux v5.0 and later kernels that > > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > > BPF JIT programs in module memory") and the memory dump > > is captured by virsh dump. > > > > Note: Another two issues remain for the memory dump captured by > > virsh dump with aarch64. > > I'm confused -- the vmcoreinfo data has been passed to the KVM host > for the virsh dump for quite some time now. Is it not passed back > to the host on aarch64? The vmcore_data shows that vmcoreinfo size is 0, so I think vmcoreinfo isn't captured by virsh dump. Am I missing something...? ./crash -d1 vmlinux-v5.4 dump.v5.4 ... vmcore_data: flags: c0 (KDUMP_LOCAL|KDUMP_ELF64) ndfd: 3 ofp: a5e81588 header_size: 30896 num_pt_load_segments: 1 pt_load_segment[0]: file_offset: 78b0 phys_start: 4000 phys_end: 26000 zero_fill: 0 elf_header: 2ed6d4e0 elf32: 0 notes32: 0 load32: 0 elf64: 2ed6d4e0 notes64: 2ed6d520 load64: 2ed6d558 sect0_64: 0 nt_prstatus: 2ed6d590 nt_prpsinfo: 0 nt_taskstruct: 0 task_struct: 0 arch_data1: (unused) arch_data2: (unused) switch_stack: 0 page_size: 0 xen_kdump_data: (unused) num_prstatus_notes: 32 num_qemu_notes: 0 vmcoreinfo: 0 size_vmcoreinfo: 0 nt_prstatus_percpu: 2ed6d590 2ed6d950 2ed6dd10 2ed6e0d0 2ed6e490 2ed6e850 2ed6ec10 2ed6efd0 2ed6f390 2ed6f750 2ed6fb10 2ed6fed0 2ed70290 2ed70650 2ed70a10 2ed70dd0 2ed71190 2ed71550 2ed71910 2ed71cd0 2ed72090 2ed72450 2ed72810 2ed72bd0 2ed72f90 2ed73350 2ed73710 2ed73ad0 2ed73e90 2ed74250 2ed74610 2ed749d0 nt_qemu_percpu: backup_src_start: 0 backup_src_size: 0 backup_offset: 0 ... Thanks, Masa > > Dave > > I > > > > 1. KASLR > >crash doesn't work in case KASLR is enabled on the guest. > >That is because the memory dump doesn't have vmcoreinfo, so we > >cannot get the relocation position. > >I suppose we need to implement calc_kaslr_offset() for aarch64. > >nokaslr with the guest kernel parameter is a workaround. > > > > 2. VA_BITS > >crash doesn't work in case the guest kernel is v5.4 and later. > >That is because the memory dump doesn't have vmcoreinfo, so we > >cannot get vabits_actual. > >I think there's no workaround so far... > > > > Masayoshi Mizuma (1): > > arm64: Fix missing offset for modules_vaddr with aarch64 guest dump > > > > arm64.c | 2 ++ > > defs.h | 3 +++ > > 2 files changed, 5 insertions(+) > > > > -- > > 2.18.1 > > > > > > -- > > Crash-utility mailing list > > Crash-utility@redhat.com > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- > Crash-utility mailing list > Crash-utility@redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
- Original Message - > From: Masayoshi Mizuma > > Fix for aarch64 with Linux v5.0 and later kernels that > contains commit 91fc957c9b1d ("arm64/bpf: don't allocate > BPF JIT programs in module memory") and the memory dump > is captured by virsh dump. > > Note: Another two issues remain for the memory dump captured by > virsh dump with aarch64. I'm confused -- the vmcoreinfo data has been passed to the KVM host for the virsh dump for quite some time now. Is it not passed back to the host on aarch64? Dave I > > 1. KASLR >crash doesn't work in case KASLR is enabled on the guest. >That is because the memory dump doesn't have vmcoreinfo, so we >cannot get the relocation position. >I suppose we need to implement calc_kaslr_offset() for aarch64. >nokaslr with the guest kernel parameter is a workaround. > > 2. VA_BITS >crash doesn't work in case the guest kernel is v5.4 and later. >That is because the memory dump doesn't have vmcoreinfo, so we >cannot get vabits_actual. >I think there's no workaround so far... > > Masayoshi Mizuma (1): > arm64: Fix missing offset for modules_vaddr with aarch64 guest dump > > arm64.c | 2 ++ > defs.h | 3 +++ > 2 files changed, 5 insertions(+) > > -- > 2.18.1 > > > -- > Crash-utility mailing list > Crash-utility@redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
[Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
From: Masayoshi Mizuma Fix for aarch64 with Linux v5.0 and later kernels that contains commit 91fc957c9b1d ("arm64/bpf: don't allocate BPF JIT programs in module memory") and the memory dump is captured by virsh dump. Note: Another two issues remain for the memory dump captured by virsh dump with aarch64. 1. KASLR crash doesn't work in case KASLR is enabled on the guest. That is because the memory dump doesn't have vmcoreinfo, so we cannot get the relocation position. I suppose we need to implement calc_kaslr_offset() for aarch64. nokaslr with the guest kernel parameter is a workaround. 2. VA_BITS crash doesn't work in case the guest kernel is v5.4 and later. That is because the memory dump doesn't have vmcoreinfo, so we cannot get vabits_actual. I think there's no workaround so far... Masayoshi Mizuma (1): arm64: Fix missing offset for modules_vaddr with aarch64 guest dump arm64.c | 2 ++ defs.h | 3 +++ 2 files changed, 5 insertions(+) -- 2.18.1 -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility