Hi Alexander, Bhupesh, Thank you for working on this, and sorry for the long delay. For the 1/3 patch, Bhupesh and I got an offlist report that makedumpfile could not be built with the patch in an old environment, which was a similar error to kexec-tools patch [1]. And "make TARGET=aarch64" on x86_64 also fails, though probably this is a rare usage. Also there is the limitation that Alexander and I pointed out [2]. So my suggestion is to remove the part of fetching register value for now. This would not make makedumpfile support all arm64 kernels, so it might be good to put it aside as a separate patch for distributions with a description of the limitation. or they can merge Bhupesh's kernel commit bbdbc11804ff into their kernel. Any other ideas? e.g. a trial-and-error might be more acceptable in this case.. Anyway, there has been a long time since I understood the arm64 changes, I need to digest it again. I might clean up your patches. Please wait for a while. [1] http://lists.infradead.org/pipermail/kexec/2020-September/021503.html [2] http://lists.infradead.org/pipermail/kexec/2020-November/021797.html Thanks, Kazu -----Original Message----- > Hi Kazu, Bhupesh, > > I am hitting the linear mapping swap issue with makedumpfile failing on > arm64 Yocto Project qemuarm64 machine with 5.8 kernel as it was discussed > several times on this mailing list: > > root@qemuarm64:~# makedumpfile -c -F /proc/vmcore > /dev/null > readpage_elf: Attempt to read non-existent page at 0x0. > readmem: type_addr: 1, addr:440, size:8 > vaddr_to_paddr_arm64: Can't read pmd > readmem: Can't convert a virtual address(ffffffc01107f94c) to physical address. > readmem: type_addr: 0, addr:ffffffc01107f94c, size:390 > check_release: Can't get the address of system_utsname. > > I've have tried Bhupesh's remaining third patch [1] from [2] series, > it does help. But I am a bit hesitant to submit it to the Yocto Project, > since Kazu pointed out [3] that this patch uses current kernel version to > make decision how __pa is handled and it may mismatch the version where > vmcore was collected, and in such case it may not operate correctly. > > In this RFC series I have tried to implement Kazu's suggestion and use > kernel version retrieved from OSRELEASE string from vmcoreinfo note. I > wonder whether it will help to merge arm64 5.4+ makedumpfile fix? Is > there anything else outstanding that prevents such merge? > > My RFC patches series does include Bhupesh's patch [1], and I posted > my modifications on top of it as separate patch for readability. > > Thanks, > Alexander > > [1] http://lists.infradead.org/pipermail/kexec/2020-September/021336.html > [2] http://lists.infradead.org/pipermail/kexec/2020-September/021333.html > [3] http://lists.infradead.org/pipermail/kexec/2020-September/021488.html > > Alexander Kamensky (2): > added way to determine kernel version that vmcore is from > arm64: use kernel version from OSRELEASE to determine linear mapping > position > > Bhupesh Sharma (1): > makedumpfile/arm64: Add support for ARMv8.2-LVA (52-bit kernel VA > support) > > arch/arm64.c | 229 ++++++++++++++++++++++++++++++++++++++++++------- > common.h | 10 +++ > makedumpfile.c | 23 +++++ > makedumpfile.h | 6 +- > 4 files changed, 234 insertions(+), 34 deletions(-) > > -- > 2.26.2 > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
