Hi Akashi, On Fri, Nov 15, 2019 at 7:29 AM AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> wrote: > > Bhupesh, > > On Fri, Nov 15, 2019 at 01:24:17AM +0530, Bhupesh Sharma wrote: > > Hi Akashi, > > > > On Wed, Nov 13, 2019 at 12:11 PM AKASHI Takahiro > > <takahiro.akashi@xxxxxxxxxx> wrote: > > > > > > Hi Bhupesh, > > > > > > Do you have a corresponding patch for userspace tools, > > > including crash util and/or makedumpfile? > > > Otherwise, we can't verify that a generated core file is > > > correctly handled. > > > > Sure. I am still working on the crash-utility related changes, but you > > can find the makedumpfile changes I posted a couple of days ago here > > (see [0]) and the github link for the makedumpfile changes can be seen > > via [1]. > > > > I will post the crash-util changes shortly as well. > > Thanks for having a look at the same. > > Thank you. > I have tested my kdump patch with a hacked version of crash > where VA_BITS_ACTUAL is calculated from tcr_el1_t1sz in vmcoreinfo. Thanks a lot for testing the changes. I will push the crash utility changes for review shortly and also Cc you to the patches. It would be great to have your Tested-by for this patch-set, if the user-space works fine for you with these changes. Regards, Bhupesh > -Takahiro Akashi > > > > [0]. http://lists.infradead.org/pipermail/kexec/2019-November/023963.html > > [1]. https://github.com/bhupesh-sharma/makedumpfile/tree/52-bit-va-support-via-vmcore-upstream-v4 > > > > Regards, > > Bhupesh > > > > > > > > Thanks, > > > -Takahiro Akashi > > > > > > On Mon, Nov 11, 2019 at 01:31:19PM +0530, Bhupesh Sharma wrote: > > > > Changes since v3: > > > > ---------------- > > > > - v3 can be seen here: > > > > http://lists.infradead.org/pipermail/kexec/2019-March/022590.html > > > > - Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo > > > > instead of PTRS_PER_PGD. > > > > - Added a new patch (via [PATCH 3/3]), which fixes a simple typo in > > > > 'Documentation/arm64/memory.rst' > > > > > > > > Changes since v2: > > > > ---------------- > > > > - v2 can be seen here: > > > > http://lists.infradead.org/pipermail/kexec/2019-March/022531.html > > > > - Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPARSEMEM > > > > ifdef sections, as suggested by Kazu. > > > > - Updated vmcoreinfo documentation to add description about > > > > 'MAX_PHYSMEM_BITS' variable (via [PATCH 3/3]). > > > > > > > > Changes since v1: > > > > ---------------- > > > > - v1 was sent out as a single patch which can be seen here: > > > > http://lists.infradead.org/pipermail/kexec/2019-February/022411.html > > > > > > > > - v2 breaks the single patch into two independent patches: > > > > [PATCH 1/2] appends 'PTRS_PER_PGD' to vmcoreinfo for arm64 arch, whereas > > > > [PATCH 2/2] appends 'MAX_PHYSMEM_BITS' to vmcoreinfo in core kernel code (all archs) > > > > > > > > This patchset primarily fixes the regression reported in user-space > > > > utilities like 'makedumpfile' and 'crash-utility' on arm64 architecture > > > > with the availability of 52-bit address space feature in underlying > > > > kernel. These regressions have been reported both on CPUs which don't > > > > support ARMv8.2 extensions (i.e. LVA, LPA) and are running newer kernels > > > > and also on prototype platforms (like ARMv8 FVP simulator model) which > > > > support ARMv8.2 extensions and are running newer kernels. > > > > > > > > The reason for these regressions is that right now user-space tools > > > > have no direct access to these values (since these are not exported > > > > from the kernel) and hence need to rely on a best-guess method of > > > > determining value of 'vabits_actual' and 'MAX_PHYSMEM_BITS' supported > > > > by underlying kernel. > > > > > > > > Exporting these values via vmcoreinfo will help user-land in such cases. > > > > In addition, as per suggestion from makedumpfile maintainer (Kazu), > > > > it makes more sense to append 'MAX_PHYSMEM_BITS' to > > > > vmcoreinfo in the core code itself rather than in arm64 arch-specific > > > > code, so that the user-space code for other archs can also benefit from > > > > this addition to the vmcoreinfo and use it as a standard way of > > > > determining 'SECTIONS_SHIFT' value in user-land. > > > > > > > > Cc: Boris Petkov <bp@xxxxxxxxx> > > > > Cc: Ingo Molnar <mingo@xxxxxxxxxx> > > > > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > > > > Cc: Jonathan Corbet <corbet@xxxxxxx> > > > > Cc: James Morse <james.morse@xxxxxxx> > > > > Cc: Mark Rutland <mark.rutland@xxxxxxx> > > > > Cc: Will Deacon <will@xxxxxxxxxx> > > > > Cc: Steve Capper <steve.capper@xxxxxxx> > > > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > > > > Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > > > Cc: Michael Ellerman <mpe@xxxxxxxxxxxxxx> > > > > Cc: Paul Mackerras <paulus@xxxxxxxxx> > > > > Cc: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> > > > > Cc: Dave Anderson <anderson@xxxxxxxxxx> > > > > Cc: Kazuhito Hagio <k-hagio@xxxxxxxxxxxxx> > > > > Cc: x86@xxxxxxxxxx > > > > Cc: linuxppc-dev@xxxxxxxxxxxxxxxx > > > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > > > Cc: linux-kernel@xxxxxxxxxxxxxxx > > > > Cc: linux-doc@xxxxxxxxxxxxxxx > > > > Cc: kexec@xxxxxxxxxxxxxxxxxxx > > > > > > > > Bhupesh Sharma (3): > > > > crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo > > > > arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo > > > > Documentation/arm64: Fix a simple typo in memory.rst > > > > > > > > Documentation/arm64/memory.rst | 2 +- > > > > arch/arm64/include/asm/pgtable-hwdef.h | 1 + > > > > arch/arm64/kernel/crash_core.c | 9 +++++++++ > > > > kernel/crash_core.c | 1 + > > > > 4 files changed, 12 insertions(+), 1 deletion(-) > > > > > > > > -- > > > > 2.7.4 > > > > > > > > > > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
