RE: [PATCH] arm64: Add a generic method of determining invalid phy-addr for calculating 'info->page_offset'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bhupesh,

Thank you for the information.
OK, I'll wait for your patch.

Kazu

On 9/10/2018 3:07 PM, Bhupesh Sharma wrote:
> Hello Kazu,
> 
> Sorry for the late reply. I was waiting for the new patches (see [1]
> and [2]) to make way upstream/or be discussed upstream, so that we can
> simplify the logic of getting the arm64 specific constructs in
> user-space utilities  like PHYS_OFFSET and KASLR_OFFSET (which are to
> be made available via both '/proc/kcore' and '/proc/vmcore' with the
> latest changes).
> 
> So, after [1], '/proc/kcore' now contains vmcoreinfo as a PT_NOTE.
> 
> I have a working version available now which allows makedumpfile to
> determine the contents required for arm64 info->page_offset to be
> calculate via the vmcoreinfo inside '/proc/kcore'. I am similarly
> working on kexec-tools and crash utility to add the same feature.
> 
> I am testing the version on multiple boards now and will soon send out
> a version for review:
> 
> [1] commit 23c85094fe1895caefdd19ef624ee687ec5f4507
> Author: Omar Sandoval <osandov@xxxxxx>
> Date:   Tue Aug 21 21:55:20 2018 -0700
> 
>     proc/kcore: add vmcoreinfo note to /proc/kcore
> 
> [2] https://www.spinics.net/lists/arm-kernel/msg675582.html
> 
> Thanks,
> Bhupesh
> 
> On Tue, Aug 21, 2018 at 8:57 PM, Kazuhito Hagio <k-hagio@xxxxxxxxxxxxx> wrote:
> > Hi Bhupesh,
> >
> > On 8/20/2018 3:45 PM, Bhupesh Sharma wrote:
> >> Commit 94c97db3fe859ca14d7b38b0ae9ee0ffb83689d2 (arm64: Get
> >> 'info->page_offset' from PT_LOAD segments to support KASLR boot cases)
> >> added a method to determine 'info->page_offset' from PT_LOAD segments
> >> for arm64 platforms.
> >>
> >> In this commit we hardcoded the NOT_PADDR_ARM64 macro as
> >> 0x0000000010a80000UL which was a valid value on
> >> qualcomm-amberwing boards.
> >>
> >> However, I was testing this change on several other arm64 boards
> >> like apm-mustang, huawei-taishan and hp-moonshot and saw that
> >> this value can vary on the basic of the "Kernel code" memory range
> >> placement.
> >>
> >> This patch determines the "Kernel code" memory range from
> >> '/proc/iomem' listing and uses the same to determine the
> >> NOT_PADDR_ARM64 value, which makes this calculation platform
> >> independent and this works well on apm-mustang, huawei-taishan,
> >> qualcomm-amberwing and hp-moonshot platforms.
> >
> > I don't have any arm64 system for now, but I think that a "Kernel code"
> > range in /proc/iomem on 2nd kernel will be different from the one on
> > 1st kernel.  Does it process /proc/vmcore correctly on 2nd kernel?
> > If it doesn't, we have to find another way..
> >
> > This is the condition for x86_64:
> >
> >     if (virt_start != NOT_KV_ADDR          ... *1 (0x0)
> >         && virt_start < __START_KERNEL_map ... *2 (0xffffffff80000000)
> >         && phys_start != NOT_PADDR) {      ... *3 (~0ULL)
> >
> > These are how we get the appropriate values on x86_64:
> >
> > # readelf -l vmcore  # I got with cp command
> > ...
> >   Type           Offset             VirtAddr           PhysAddr
> >                  FileSiz            MemSiz              Flags  Align
> >   NOTE           0x0000000000001000 0x0000000000000000 0x0000000000000000 // PT_NOTE
> >                  0x00000000000009c8 0x00000000000009c8         0
> >   LOAD           0x0000000000002000 0xffffffff96c00000 0x000000000f800000 skipped by *2
> >                  0x0000000001656000 0x0000000001656000  RWE    0
> >   LOAD           0x0000000001658000 0xffff976b00001000 0x0000000000001000 picked
> >                  0x000000000009ec00 0x000000000009ec00  RWE    0
> >   LOAD           0x00000000016f7000 0xffff976b00100000 0x0000000000100000
> >                  0x000000002cf00000 0x000000002cf00000  RWE    0
> >   LOAD           0x000000002e5f7000 0xffff976b35000000 0x0000000035000000
> >                  0x000000004aff7000 0x000000004aff7000  RWE    0
> >
> > # readelf -l /proc/kcore
> > ...
> >   Type           Offset             VirtAddr           PhysAddr
> >                  FileSiz            MemSiz              Flags  Align
> >   NOTE           0x0000000000000238 0x0000000000000000 0x0000000000000000 // PT_NOTE
> >                  0x00000000000011e4 0x0000000000000000         0
> >   LOAD           0x00007fffff602000 0xffffffffff600000 0xffffffffffffffff skipped by *3
> >                  0x0000000000800000 0x0000000000800000  RWE    1000
> >   LOAD           0x00007fff96c02000 0xffffffff96c00000 0x000000000f800000 skipped by *2
> >                  0x0000000001656000 0x0000000001656000  RWE    1000
> >   LOAD           0x00003228c0002000 0xffffb228c0000000 0xffffffffffffffff skipped by *3
> >                  0x00001fffffffffff 0x00001fffffffffff  RWE    1000
> >   LOAD           0x00007fffc0002000 0xffffffffc0000000 0xffffffffffffffff skipped by *2
> >                  0x000000003f000000 0x000000003f000000  RWE    1000
> >   LOAD           0x0000176b00003000 0xffff976b00001000 0x0000000000001000 picked
> >                  0x000000000009e000 0x000000000009e000  RWE    1000
> >   LOAD           0x00006f1880002000 0xffffef1880000000 0xffffffffffffffff
> >                  0x0000000000003000 0x0000000000003000  RWE    1000
> >   LOAD           0x0000176b00102000 0xffff976b00100000 0x0000000000100000
> >                  0x000000007fef7000 0x000000007fef7000  RWE    1000
> >   LOAD           0x00006f1880006000 0xffffef1880004000 0xffffffffffffffff
> >                  0x0000000001ffc000 0x0000000001ffc000  RWE    1000
> >
> > If a value like NOT_PADDR_ARM64 is needed, can we find the condition
> > which consists of only static and common values first?
> > It would be better that there is something evidence or data as well.
> >
> > Thanks,
> > Kazu
> >
> >>
> >> Here are some logs on my huawei-taishan board with kernel version
> >> 4.18.0-rc8:
> >>
> >> The kernel version is not supported.
> >> The makedumpfile operation may be incomplete.
> >>
> >> TYPE          PAGES                   EXCLUDABLE      DESCRIPTION
> >> ----------------------------------------------------------------------
> >> ZERO          83081                   yes             Pages filled with zero
> >> NON_PRI_CACHE 6330                    yes             Cache pages without private flag
> >> PRI_CACHE     927                     yes             Cache pages with private flag
> >> USER          2659                    yes             User process pages
> >> FREE          4053998                 yes             Free pages
> >> KERN_DATA     35331                   no              Dumpable kernel data
> >>
> >> page size:            65536
> >> Total pages on system:        4182326
> >> Total size on system: 274092916736     Byte
> >>
> >> Fixes: 94c97db3fe859ca14d7b38b0ae9ee0ffb83689d2 (arm64: Get
> >>       'info->page_offset' from PT_LOAD segments to support KASLR boot
> >>       cases)
> >>
> >> Signed-off-by: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
> >> ---
> >>  arch/arm64.c   | 26 ++++++++++++++++++++++++--
> >>  makedumpfile.h |  1 -
> >>  2 files changed, 24 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm64.c b/arch/arm64.c
> >> index 362609668ea2..e0b30c812124 100644
> >> --- a/arch/arm64.c
> >> +++ b/arch/arm64.c
> >> @@ -303,10 +303,25 @@ get_xen_info_arm64(void)
> >>       return ERROR;
> >>  }
> >>
> >> +/* We want to exclude the kernel code mem region while calculating the
> >> + * info->page_offset for arm64 arch
> >> + */
> >> +static struct memory_range kernel_code_mem_range;
> >> +
> >> +static int kernel_code_resource_callback(void *data, int nr,
> >> +                                       char *str,
> >> +                                       unsigned long base,
> >> +                                       unsigned long length)
> >> +{
> >> +     kernel_code_mem_range.start = base;
> >> +     kernel_code_mem_range.end   = base + length - 1;
> >> +     return 0;
> >> +}
> >> +
> >>  int
> >>  get_versiondep_info_arm64(void)
> >>  {
> >> -     int i;
> >> +     int i, ret;
> >>       unsigned long long phys_start;
> >>       unsigned long long virt_start;
> >>       ulong _stext;
> >> @@ -333,6 +348,13 @@ get_versiondep_info_arm64(void)
> >>               return FALSE;
> >>       }
> >>
> >> +     ret = iomem_for_each_line("Kernel code\n",
> >> +                                     kernel_code_resource_callback, NULL);
> >> +     if (ret != 1) {
> >> +             ERRMSG("Cannot find a proper Kernel code memory range in /proc/iomem\n");
> >> +             return FALSE;
> >> +     }
> >> +
> >>       if (get_num_pt_loads()) {
> >>               for (i = 0;
> >>                   get_pt_load(i, &phys_start, NULL, &virt_start, NULL);
> >> @@ -340,7 +362,7 @@ get_versiondep_info_arm64(void)
> >>                       if (virt_start != NOT_KV_ADDR
> >>                           && virt_start < __START_KERNEL_map
> >>                           && phys_start != NOT_PADDR
> >> -                         && phys_start != NOT_PADDR_ARM64) {
> >> +                         && phys_start != kernel_code_mem_range.start) {
> >>                               info->page_offset = virt_start - phys_start;
> >>                               DEBUG_MSG("info->page_offset: %lx, VA_BITS: %d\n",
> >>                                               info->page_offset, va_bits);
> >> diff --git a/makedumpfile.h b/makedumpfile.h
> >> index 3244d31ae43a..9fefe150829f 100644
> >> --- a/makedumpfile.h
> >> +++ b/makedumpfile.h
> >> @@ -544,7 +544,6 @@ unsigned long get_kvbase_arm64(void);
> >>  #define KVBASE                       get_kvbase_arm64()
> >>
> >>  #define __START_KERNEL_map   (0xffffffff80000000UL)
> >> -#define NOT_PADDR_ARM64              (0x0000000010a80000UL)
> >>
> >>  #endif /* aarch64 */
> >>
> >> --
> >> 2.7.4
> >>
> >
> >

_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux