Hi Pratyush, Thanks for your help! but please see my reply inline. Regards! Yanjiang > -----Original Message----- > From: Pratyush Anand [mailto:pratyush.anand@xxxxxxxxx] > Sent: 2018年5月29日 23:04 > To: Jin, Yanjiang <yanjiang.jin@xxxxxxxxxxxxxxxx> > Cc: kexec@xxxxxxxxxxxxxxxxxxx; jinyanjiang@xxxxxxxxx; horms@xxxxxxxxxxxx > Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel > > Hi Yanjiang, > > On Fri, May 11, 2018 at 11:30 AM, Yanjiang Jin <yanjiang.jin@xxxxxxxxxxxxxxxx> > wrote: > > Now, according to the kernel's memory.h, converting a virtual address > > to a physical address should be done like below: > > > > phys_addr_t __x = (phys_addr_t)(x); \ > > __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : > > \ > > (__x - kimage_voffset); }) > > > > We just set PHYS_OFFSET as the start address of the first usable > > memory block in SYSTEM RAM before, but it is defined in kernel as below: > > > > define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; }) > > > > So we need to calculate PHYS_OFFSET based on some proc nodes. > > > > Without this change, we would get a wrong vmcore. > > Assume that we have a system as below: > > > > Virtual kernel memory layout: > > > > memory : 0xffff800000200000 - 0xffff801800000000 > > > > The first iomem block: > > > > 00200000-0021ffff : reserved > > > > But in vmcore's elf header, the corresponding memory block as below, > > the last 2M bytes lost due to "iomem" starts from 0x200000. > > > > Type VirtAddr > > LOAD 0xffff80017fe00000 > > > > If an application, for example, vmcore-dmesg, wants to access the > > kernel symbol which is located in the last 2M address, it would fail > > with the below error: > > > > "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?" > > I think, fix might not be correct. > > Problem is in vmcore-dmesg and that should be fixed and not the kexec. > See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec- > tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261). Firstly, for my patch, vmcore-dmesg is just an auxiliary application to help to reproduce this issue. The function, which is to generate vmcore, is the root cause. On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone git repo. Even we want to fix vmcore-dmesg, we still need to send the patch to kexec-tools, right? Yanjiang > How symbols are extracted from vmcore. > > You do have "NUMBER(PHYS_OFFSET)=" information in vmcore. > > You can probably see makedumpfile code, that how to extract information from > "NUMBER". I have seen makedumpfile before, NUMBER(number) is just read a number from vmcore. But as I show before, the root issue is vmcore contains a wrong number, my patch is to fix the vmcore generating issue, we can't read vmcore at this point since we don't have vmcore yet. NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number)) Yanjiang > > Once you know the real PHYS_OFFSET (which could have been random if KASLR is > enabled), you can fix the problem you are seeing. I have both validated with/without KASLR, all of them worked well after applying my patch. Yanjiang > > Regards > Pratyush This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
