From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 19 Jun 2018 10:40:45 +0100 Subject: [PATCH] arm64/mm: Introduce a variable to hold base address of linear region In-Reply-To: <6860c284f1c74faa95edd6cf866ec80d@HXTBJIDCEMVIW02.hxtcorp.net> References: <3a05cd0e-466e-4fb6-a78a-4b363e21aaab@arm.com> <92ff5220-f863-4edc-bc9f-bd802d2efa9c@arm.com> <20180619085541.GB13984@arm.com> <6860c284f1c74faa95edd6cf866ec80d@HXTBJIDCEMVIW02.hxtcorp.net> Message-ID: <20180619094045.GD13984@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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