> -----Original Message----- > From: Will Deacon [mailto:will.deacon@xxxxxxx] > Sent: 2018年6月19日 17:41 > To: Jin, Yanjiang <yanjiang.jin@xxxxxxxxxxxxxxxx> > Cc: James Morse <james.morse@xxxxxxx>; Bhupesh Sharma > <bhsharma@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; Ard > Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Catalin Marinas > <catalin.marinas@xxxxxxx>; Kexec Mailing List <kexec@xxxxxxxxxxxxxxxxxxx>; > AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>; Bhupesh SHARMA > <bhupesh.linux@xxxxxxxxx>; linux-arm-kernel <linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx> > Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of > linear region > > On Tue, Jun 19, 2018 at 09:34:56AM +0000, Jin, Yanjiang wrote: > > > On Tue, Jun 19, 2018 at 03:02:15AM +0000, Jin, Yanjiang wrote: > > > > > You seem to be using this for user-space phys_to_virt() based on > > > > > values found in /proc/iomem. This should give you what you want, > > > > > and isolate your user-space from the kernel's unexpected naming of > variables. > > > > > > > > I don't know could I simplify this problem? > > > > Let's ignore what memstart_addr represents here, we just want to > > > > implement > > > > phys_to_virt() in an userspace applications(kexec-tools or others). > > > > > > > > ARM64 Kernel has a below definition: > > > > > > > > #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | > > > PAGE_OFFSET) > > > > > > > > So userspace app must know PHYS_OFFSET(equal to memstart_addr now). > > > > Seems this is very simple, but memstart_addr has gone through > > > > several operations in arm64_memblock_init() depends on different > > > > Kernel configurations, so userspace app needs to know many > > > > additional definitions as > > > following: > > > > > > > > memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP), > > > > ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET, > > > > memblock_end_of_DRAM(), IS_ENABLED(CONFIG_RANDOMIZE_BASE), > > > > memstart_offset_seed. > > > > > > > > It is hard to know all above in kexec-tools now. Originally I > > > > planned to read memstart_addr's value from "/dev/mem", but someone > > > > thought not all Kernels enable "/dev/mem", we'd better find a more > > > > generic approach. So we want to get some suggestions from ARM kernel > community. > > > > Can we export this variable in Kernel side through sysconf() or > > > > other similar methods? Or someone can provide an effect way to get > > > > memstart_addr's value? > > > > > > I thought the suggestion from James was to expose this via an ELF > > > NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm > not sure about it)? > > > > Thanks for your reply firstly. But same as DEVMEM, kcore is not a > > must-have, so we can't depend on it. > > Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps. > > > On the other hand, phys_to_virt() is called during generating vmcore > > in Kexec-tools, vmcore also can't help this issue. > > I don't understand this part. If you have the vmcore in your hand, why can't you > grok the pv offset from the note and use that in phys_to_virt()? It is a chicken-and-egg issue. phys_to virt() is for crashdump setup. To generate vmcore, we must call phys_to_virt(). At this point, no vmcore exists. Yanjiang > > > Unfortunately, not all platforms support analyzing Kernel config in > > userspace application, so Kexec-tools can't know some key kernel options. > > If not so, we can simulate the whole arm64_memblock_init() progress > > in kexec-tools. > > I don't understand what the kernel config has to do with kexec tools. I mean that if we can know kernel .config in all circumstances, we can calculate memstart_addr as below in Kexec-tools: memstart_addr = round_down(memblock_start_of_DRAM(), ARM64_MEMSTART_ALIGN); #if defined(CONFIG_SPARSEMEM_VMEMMAP) && ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS #define ARM64_MEMSTART_ALIGN (1UL << SECTION_SIZE_BITS) ...... #endif #define ARM64_MEMSTART_SHIFT PMD_SHIFT #if CONFIG_PGTABLE_LEVELS > 2 #define PMD_SHIFT ARM64_HW_PGTABLE_LEVEL_SHIFT(2) ........... #endif Yanjiang > > Will 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
