1:24 p.m.
----- 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
> > > >
> > >
> >
> >
>