[Crash-utility] [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump

Dave Anderson anderson at redhat.com
Mon Jan 27 15:17:51 UTC 2020



----- Original Message -----
> On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: Masayoshi Mizuma <m.mizuma at jp.fujitsu.com>
> > > 
> > > 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: 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 at redhat.com
> > > https://www.redhat.com/mailman/listinfo/crash-utility
> > > 
> > 
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> > 
> 
> 




More information about the Crash-utility mailing list