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: ffffa5e81588 > > > > > > > > header_size: 30896 > > > > > > > > num_pt_load_segments: 1 > > > > > > > > pt_load_segment[0]: > > > > > > > > file_offset: 78b0 > > > > > > > > phys_start: 40000000 > > > > > > > > phys_end: 260000000 > > > > > > > > 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: > > > > > > > > 000000002ed6d590 000000002ed6d950 000000002ed6dd10 > > > > > > > > 000000002ed6e0d0 > > > > > > > > 000000002ed6e490 000000002ed6e850 000000002ed6ec10 > > > > > > > > 000000002ed6efd0 > > > > > > > > 000000002ed6f390 000000002ed6f750 000000002ed6fb10 > > > > > > > > 000000002ed6fed0 > > > > > > > > 000000002ed70290 000000002ed70650 000000002ed70a10 > > > > > > > > 000000002ed70dd0 > > > > > > > > 000000002ed71190 000000002ed71550 000000002ed71910 > > > > > > > > 000000002ed71cd0 > > > > > > > > 000000002ed72090 000000002ed72450 000000002ed72810 > > > > > > > > 000000002ed72bd0 > > > > > > > > 000000002ed72f90 000000002ed73350 000000002ed73710 > > > > > > > > 000000002ed73ad0 > > > > > > > > 000000002ed73e90 000000002ed74250 000000002ed74610 > > > > > > > > 000000002ed749d0 > > > > > > > > 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(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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Crash-utility mailing list > > > > > Crash-utility(a)redhat.com > > > > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > > > > > > > > > > > > > > > >