8:46 a.m.
From: Masayoshi Mizuma <m.mizuma(a)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.
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
8:46 a.m.
New subject: [PATCH 1/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
From: Masayoshi Mizuma <m.mizuma(a)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.
Without the patch, crash cannot find kimage_voffset so it
fails to run, like as:
# crash vmlinux Guest.dump
...
WARNING: kimage_voffset cannot be determined from the dumpfile.
Try using the command line option: --machdep kimage_voffset=<addr>
...
crash: read error: kernel virtual address: ffff0000112db978 type:
"possible"
WARNING: cannot read cpu_possible_map
...
crash: vmlinux and Guest.dump do not match!
...
#
This issue happens on the memory dump which is captured by virsh dump
because kimage_voffset isn't stored if it's captured by virsh dump.
Signed-off-by: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
---
arm64.c | 2 ++
defs.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/arm64.c b/arm64.c
index 7662d71..0831231 100644
--- a/arm64.c
+++ b/arm64.c
@@ -242,6 +242,8 @@ arm64_init(int when)
ms->modules_vaddr = ARM64_VA_START;
if (kernel_symbol_exists("kasan_init"))
ms->modules_vaddr += ARM64_KASAN_SHADOW_SIZE;
+ if (kernel_symbol_exists("bpf_jit_alloc_exec"))
+ ms->modules_vaddr += BPF_JIT_REGION_SIZE;
ms->modules_end = ms->modules_vaddr + ARM64_MODULES_VSIZE -1;
}
diff --git a/defs.h b/defs.h
index efa40b9..867da74 100644
--- a/defs.h
+++ b/defs.h
@@ -3164,6 +3164,9 @@ typedef signed int s32;
#define ARM64_MODULES_VSIZE MEGABYTES(128)
#define ARM64_KASAN_SHADOW_SIZE (1UL << (machdep->machspec->VA_BITS - 3))
+/* only used for v5.0 or later */
+#define BPF_JIT_REGION_SIZE MEGABYTES(128)
+
/*
* The following 3 definitions are the original values, but are obsolete
* for 3.17 and later kernels because they are now build-time calculations.
--
2.18.1
8:56 a.m.
New subject: [PATCH 0/1] arm64: Fix missing offset for modules_vaddr with aarch64 guest dump
----- Original Message -----
From: Masayoshi Mizuma <m.mizuma(a)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?
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
9:06 a.m.
On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote:
----- Original Message -----
> From: Masayoshi Mizuma <m.mizuma(a)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...?
./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
9:11 a.m.
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 <m.mizuma(a)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 captured the memory dump by:
virsh dump --crash --memory-only <Guest> <Dumpfile>
- Masa
./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
>
9:17 a.m.
----- Original Message -----
On Mon, Jan 27, 2020 at 09:56:53AM -0500, Dave Anderson wrote:
>
>
> ----- Original Message -----
> > From: Masayoshi Mizuma <m.mizuma(a)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(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
>
9:22 a.m.
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 <m.mizuma(a)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 ..."?
Yes, I'm using --memory-only option like as:
virsh dump --crash --memory-only <Guest> <Dumpfile>
- 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
> >
>
>
9:31 a.m.
----- 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 <m.mizuma(a)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 ..."?
Yes, I'm using --memory-only option like as:
virsh dump --crash --memory-only <Guest> <Dumpfile>
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: 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
> > >
> >
> >
>
10:04 a.m.
----- 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 <m.mizuma(a)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 ..."?
>
> Yes, I'm using --memory-only option like as:
>
> virsh dump --crash --memory-only <Guest> <Dumpfile>
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: 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
10:27 a.m.
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 <m.mizuma(a)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
..."?
> >
> > Yes, I'm using --memory-only option like as:
> >
> > virsh dump --crash --memory-only <Guest> <Dumpfile>
>
> 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: 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
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
10:43 a.m.
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 <m.mizuma(a)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
..."?
> >
> > Yes, I'm using --memory-only option like as:
> >
> > virsh dump --crash --memory-only <Guest> <Dumpfile>
>
> 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: 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
>
11:15 a.m.
----- 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: 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
> >
>
12:02 p.m.
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: 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
> > >
> >
>
>
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
> > > >
> > >
> >
> >
>
1:42 p.m.
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: 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
> > > > >
> > > >
> > >
> > >
> >
>
>
1796
days inactive
1796
days old
devel@lists.crash-utility.osci.io
14 comments
2 participants
participants (2)
-
Dave Anderson -
Masayoshi Mizuma