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 1/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.
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=
...
crash: read error: kernel virtual address: 112db978 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
---
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_SIZEMEGABYTES(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
--
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
Re: [Crash-utility] Extensions: ptdump update v1.0.7
- Original Message - > Hi Dave, > > The attached file is updated extension module ptdump v1.0.7. > Please replace old one in extension site [1] with this tarball. > > Changelog: > - ptdump: fix build warning: warning: this ‘if’ clause does not guard > - ptdump: fix failure: ptdump: invalid size request: 0 type: "read page for > write" > - ptdump: fix heap memory and fd leak when fault happens > > md5sum: > b548afa3c44b6e7f81bce020297a1572 > > [1] http://people.redhat.com/anderson/extensions.html#PTDUMP > > -- > Thanks. > HATAYAMA, Daisuke > Thanks Daisuke -- done! Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
