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).
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".
Once you know the real PHYS_OFFSET (which could have been random if
KASLR is enabled), you can fix the problem you are seeing.
Regards
Pratyush
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
