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()? > 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. Will _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
