[PATCH] arm64/mm: Introduce a variable to hold base address of linear region

[will.deacon@arm.com (Will Deacon)]

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