[PATCH] How to validate this patch

[PATCH] How to validate this patch

[Yanjiang Jin]

I have a arm64 system, I can find the virtural memory layout during booting:

Virtual kernel memory layout:
.............................
    memory  : 0xffff800000200000 - 0xffff801800000000   ( 98302 MB)

Then I can read the elf_info in vmcore:

readelf -l vmcore

Program Headers:
Type Offset             VirtAddr           PhysAddr            FileSize
...............................................................................

LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000 0x0000001680000000

The end of vmcore's VirtAddr is

(0xffff80017fe00000 + 0x0000001680000000) = 0xFFFF8017FFE00000

The end of vmlinux's VirtAddr is

0xffff801800000000

They have 0x20000 offset.

If we use vmcore-dmesg to read the log_buf from vmcore, we would get
the below error:

vmcore-dmesg vmcore

"No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"

Since on my system, log_buf is in 0xffff8017ffe90000, it exceeds the end
of vmcore VirtAddr.

With my patch, vmcore-dmesg can read all dmesg info happily.

Yanjiang Jin (1):
  arm64: update PHYS_OFFSET to conform to kernel

 kexec/arch/arm64/kexec-arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)

--
1.8.3.1




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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Yanjiang Jin]

Now, according to the kernel's memory.h, converting a virtual address to
a physical address should be done like below:

        phys_addr_t __x = (phys_addr_t)(x);
\
        __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :
\
                                 (__x - kimage_voffset); })

We just set PHYS_OFFSET as the start address of the first usable memory
block in SYSTEM RAM before, but it is defined in kernel as below:

define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })

So we need to calculate PHYS_OFFSET based on some proc nodes.

Without this change, we would get a wrong vmcore.
Assume that we have a system as below:

Virtual kernel memory layout:

 memory  : 0xffff800000200000 - 0xffff801800000000

The first iomem block:

 00200000-0021ffff : reserved

But in vmcore's elf header, the corresponding memory block as below,
the last 2M bytes lost due to "iomem" starts from 0x200000.

  Type     VirtAddr
  LOAD     0xffff80017fe00000

If an application, for example, vmcore-dmesg, wants to access the
kernel symbol which is located in the last 2M address, it would
fail with the below error:

  "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"

Signed-off-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
---
 kexec/arch/arm64/kexec-arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 100 insertions(+)

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 62f3758..d9e65fb 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -14,6 +14,8 @@
 #include <sys/stat.h>
 #include <linux/elf-em.h>
 #include <elf.h>
+#include <sys/mman.h>
+#include <fcntl.h>

 #include "kexec.h"
 #include "kexec-arm64.h"
@@ -33,6 +35,12 @@
 #define PROP_ELFCOREHDR "linux,elfcorehdr"
 #define PROP_USABLE_MEM_RANGE "linux,usable-memory-range"

+#define DEV_MEM "/dev/mem"
+
+#define ALIGN_MASK(x, y) (((x) + (y)) & ~(y))
+#define ALIGN(x, y)    ALIGN_MASK(x, (y) - 1)
+#define BUFSIZE  (256)
+
 /* Global varables the core kexec routines expect. */

 unsigned char reuse_initrd;
@@ -660,6 +668,96 @@ unsigned long phys_to_virt(struct crash_elf_info *elf_info,
        return v;
 }

+static uint64_t get_kernel_paddr(void)
+{
+       uint64_t start;
+
+       if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
+               dbgprintf("kernel load physical addr start = 0x%" PRIu64 "\n",
+                       start);
+               return start;
+       }
+
+       fprintf(stderr, "Cannot determine kernel physical load addr\n");
+       exit(3);
+}
+
+static uint64_t get_kimage_voffset(void)
+{
+       uint64_t kern_vaddr_start;
+       uint64_t kern_paddr_start;
+
+       kern_paddr_start = get_kernel_paddr();
+       kern_vaddr_start = get_kernel_sym("_text");
+
+       return kern_vaddr_start - kern_paddr_start;
+}
+
+static uint64_t kimg_to_phys(uint64_t vaddr)
+{
+       return vaddr - get_kimage_voffset();
+}
+
+static void *map_addr(int fd, unsigned long size, off_t offset)
+{
+       unsigned long page_size = getpagesize();
+       unsigned long map_offset = offset & (page_size - 1);
+       size_t len = ALIGN(size + map_offset, page_size);
+       void *result;
+
+       result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
+       if (result == MAP_FAILED) {
+               fprintf(stderr,
+                       "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
+                       (unsigned long long)offset, size, strerror(errno));
+               exit(5);
+       }
+       return result + map_offset;
+}
+
+static void unmap_addr(void *addr, unsigned long size)
+{
+       unsigned long page_size = getpagesize();
+       unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
+       size_t len = ALIGN(size + map_offset, page_size);
+       int ret;
+
+       addr -= map_offset;
+
+       ret = munmap(addr, len);
+       if (ret < 0) {
+               fprintf(stderr, "munmap failed: %s\n",
+                       strerror(errno));
+               exit(6);
+       }
+}
+
+static void init_phys_offset(void)
+{
+       int fd;
+       uint64_t phys_offset;
+       uint64_t memstart_addr_paddr;
+       void *memstart_addr_vaddr;
+
+       memstart_addr_paddr = kimg_to_phys(get_kernel_sym("memstart_addr"));
+
+       fd = open(DEV_MEM, O_RDONLY);
+       if (fd < 0) {
+               fprintf(stderr, "Cannot open " DEV_MEM ": %s\n",
+                       strerror(errno));
+               exit(3);
+       }
+
+       memstart_addr_vaddr = map_addr(fd,
+                       sizeof(memstart_addr_paddr), memstart_addr_paddr);
+
+       phys_offset = *(uint64_t *)memstart_addr_vaddr;
+       unmap_addr(memstart_addr_vaddr, sizeof(memstart_addr_paddr));
+       close(fd);
+
+       set_phys_offset(phys_offset);
+}
+
 /**
  * add_segment - Use virt_to_phys when loading elf files.
  */
@@ -731,6 +829,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
        unsigned int count;
        int result;

+       init_phys_offset();
+
        result = get_memory_ranges_iomem(array, &count);

        *range = result ? NULL : array;
--
1.8.3.1




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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Baoquan He]

On 05/11/18 at 02:00pm, Yanjiang Jin wrote:
> Now, according to the kernel's memory.h, converting a virtual address to
> a physical address should be done like below:
> 
>         phys_addr_t __x = (phys_addr_t)(x);
> \
>         __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :
> \
>                                  (__x - kimage_voffset); })
> 
> We just set PHYS_OFFSET as the start address of the first usable memory
> block in SYSTEM RAM before, but it is defined in kernel as below:
> 
> define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
> 
> So we need to calculate PHYS_OFFSET based on some proc nodes.
> 
> Without this change, we would get a wrong vmcore.
> Assume that we have a system as below:
> 
> Virtual kernel memory layout:

Add Bhupesh to the CC list, he should has thougts for this issue since
he takes care of arm64 issues.

Thanks
Baoquan

> 
>  memory  : 0xffff800000200000 - 0xffff801800000000
> 
> The first iomem block:
> 
>  00200000-0021ffff : reserved
> 
> But in vmcore's elf header, the corresponding memory block as below,
> the last 2M bytes lost due to "iomem" starts from 0x200000.
> 
>   Type     VirtAddr
>   LOAD     0xffff80017fe00000
> 
> If an application, for example, vmcore-dmesg, wants to access the
> kernel symbol which is located in the last 2M address, it would
> fail with the below error:
> 
>   "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
> 
> Signed-off-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
> ---
>  kexec/arch/arm64/kexec-arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 100 insertions(+)
> 
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 62f3758..d9e65fb 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -14,6 +14,8 @@
>  #include <sys/stat.h>
>  #include <linux/elf-em.h>
>  #include <elf.h>
> +#include <sys/mman.h>
> +#include <fcntl.h>
> 
>  #include "kexec.h"
>  #include "kexec-arm64.h"
> @@ -33,6 +35,12 @@
>  #define PROP_ELFCOREHDR "linux,elfcorehdr"
>  #define PROP_USABLE_MEM_RANGE "linux,usable-memory-range"
> 
> +#define DEV_MEM "/dev/mem"
> +
> +#define ALIGN_MASK(x, y) (((x) + (y)) & ~(y))
> +#define ALIGN(x, y)    ALIGN_MASK(x, (y) - 1)
> +#define BUFSIZE  (256)
> +
>  /* Global varables the core kexec routines expect. */
> 
>  unsigned char reuse_initrd;
> @@ -660,6 +668,96 @@ unsigned long phys_to_virt(struct crash_elf_info *elf_info,
>         return v;
>  }
> 
> +static uint64_t get_kernel_paddr(void)
> +{
> +       uint64_t start;
> +
> +       if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
> +               dbgprintf("kernel load physical addr start = 0x%" PRIu64 "\n",
> +                       start);
> +               return start;
> +       }
> +
> +       fprintf(stderr, "Cannot determine kernel physical load addr\n");
> +       exit(3);
> +}
> +
> +static uint64_t get_kimage_voffset(void)
> +{
> +       uint64_t kern_vaddr_start;
> +       uint64_t kern_paddr_start;
> +
> +       kern_paddr_start = get_kernel_paddr();
> +       kern_vaddr_start = get_kernel_sym("_text");
> +
> +       return kern_vaddr_start - kern_paddr_start;
> +}
> +
> +static uint64_t kimg_to_phys(uint64_t vaddr)
> +{
> +       return vaddr - get_kimage_voffset();
> +}
> +
> +static void *map_addr(int fd, unsigned long size, off_t offset)
> +{
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = offset & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
> +       void *result;
> +
> +       result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
> +       if (result == MAP_FAILED) {
> +               fprintf(stderr,
> +                       "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
> +                       (unsigned long long)offset, size, strerror(errno));
> +               exit(5);
> +       }
> +       return result + map_offset;
> +}
> +
> +static void unmap_addr(void *addr, unsigned long size)
> +{
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
> +       int ret;
> +
> +       addr -= map_offset;
> +
> +       ret = munmap(addr, len);
> +       if (ret < 0) {
> +               fprintf(stderr, "munmap failed: %s\n",
> +                       strerror(errno));
> +               exit(6);
> +       }
> +}
> +
> +static void init_phys_offset(void)
> +{
> +       int fd;
> +       uint64_t phys_offset;
> +       uint64_t memstart_addr_paddr;
> +       void *memstart_addr_vaddr;
> +
> +       memstart_addr_paddr = kimg_to_phys(get_kernel_sym("memstart_addr"));
> +
> +       fd = open(DEV_MEM, O_RDONLY);
> +       if (fd < 0) {
> +               fprintf(stderr, "Cannot open " DEV_MEM ": %s\n",
> +                       strerror(errno));
> +               exit(3);
> +       }
> +
> +       memstart_addr_vaddr = map_addr(fd,
> +                       sizeof(memstart_addr_paddr), memstart_addr_paddr);
> +
> +       phys_offset = *(uint64_t *)memstart_addr_vaddr;
> +       unmap_addr(memstart_addr_vaddr, sizeof(memstart_addr_paddr));
> +       close(fd);
> +
> +       set_phys_offset(phys_offset);
> +}
> +
>  /**
>   * add_segment - Use virt_to_phys when loading elf files.
>   */
> @@ -731,6 +829,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>         unsigned int count;
>         int result;
> 
> +       init_phys_offset();
> +
>         result = get_memory_ranges_iomem(array, &count);
> 
>         *range = result ? NULL : array;
> --
> 1.8.3.1
> 
> 
> 
> 
> 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Bhupesh Sharma]

Thanks Bao for adding me to the Cc list.

Hi Yanjiang Jin,

Thanks for the patch. I have a few queries, please see them inline:

On 05/11/2018 11:30 AM, Yanjiang Jin wrote:
> Now, according to the kernel's memory.h, converting a virtual address to
> a physical address should be done like below:
> 
>          phys_addr_t __x = (phys_addr_t)(x);
> \
>          __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :
> \
>                                   (__x - kimage_voffset); })
> 
> We just set PHYS_OFFSET as the start address of the first usable memory
> block in SYSTEM RAM before, but it is defined in kernel as below:
> 
> define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
> 
> So we need to calculate PHYS_OFFSET based on some proc nodes.
> 
> Without this change, we would get a wrong vmcore.
> Assume that we have a system as below:
> 
> Virtual kernel memory layout:
> 
>   memory  : 0xffff800000200000 - 0xffff801800000000
> 
> The first iomem block:
> 
>   00200000-0021ffff : reserved
> 
> But in vmcore's elf header, the corresponding memory block as below,
> the last 2M bytes lost due to "iomem" starts from 0x200000.
> 
>    Type     VirtAddr
>    LOAD     0xffff80017fe00000
> 
> If an application, for example, vmcore-dmesg, wants to access the
> kernel symbol which is located in the last 2M address, it would
> fail with the below error:
> 
>    "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"

Hmmm, I understand your concern, but I cannot reproduce this issue on 
apm mustang and qualcomm amberwing boards which I am using.

I have a few comments on this patch but before I jump to the same, can 
you please help me with the following (so that I have a better 
understanding of the issue):

- Can you please share the underlying kernel version you are using for 
reproducing this issue. I used 4.16 arm64 kernel (both _with_ and 
_without_ kaslr enabled), but I cannot reproduce this issue).

- Also can you please share the output of the 'kexec -p' command with 
the debug messages enabled (i.e. use -d flag).

- Here are some details of the environment and the logs on apm mustang 
board with the 4.16 kernel and upstream kexec-tools:

(1)
# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname 
-r`.img --reuse-cmdline -d
<snip..>

Try gzip decompression.
Try LZMA decompression.
get_memory_ranges_iomem_cb: 0000004000000000 - 00000040001fffff :  reserved
get_memory_ranges_iomem_cb: 0000004000200000 - 00000041fa59ffff : System RAM
get_memory_ranges_iomem_cb: 00000041fa5a0000 - 00000041fa9dffff : reserved
get_memory_ranges_iomem_cb: 00000041fa9e0000 - 00000041ff99ffff : System RAM
get_memory_ranges_iomem_cb: 00000041ff9a0000 - 00000041ff9affff : reserved
get_memory_ranges_iomem_cb: 00000041ff9b0000 - 00000041ff9bffff : System RAM
get_memory_ranges_iomem_cb: 00000041ff9c0000 - 00000041ff9effff : reserved
get_memory_ranges_iomem_cb: 00000041ff9f0000 - 00000041ffffffff : System RAM
elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 00000040efe00000
image_arm64_load: text_offset:    0000000000080000
image_arm64_load: image_size:     0000000001680000
image_arm64_load: phys_offset:    0000004000000000
image_arm64_load: vp_offset:      ffffffffffffffff
image_arm64_load: PE format:      yes
<snip..>

So, phys_offset is '0x0000004000000000' in my case.

Also, the 1st entry in '/proc/iomem' indicated the following 'reserved' 
entry:
get_memory_ranges_iomem_cb: 0000004000000000 - 00000040001fffff :  reserved

(2)

# dmesg | grep -i "Virtual kernel" -A 15
[    0.000000] Virtual kernel memory layout:
< snip..>

[    0.000000]     memory  : 0xffff800000000000 - 0xffff800200000000   ( 
8192 MB)

(3)

# objdump -p vmcore

vmcore:     file format elf64-littleaarch64

Program Header:

<snip..>
     LOAD off    0x0000000022a8190c vaddr 0xffff8001ff9f0000 paddr 
0x00000041ff9f0000 align 2**0
          filesz 0x0000000000610000 memsz 0x0000000000610000 flags rwx
private flags = 0:

So, the last entry in the vmcore file is also correct, base = 
0xffff8001ff9f0000, size = 0x0000000000610000, which implies
base + size = 0xFFFF800200000000

This tallies with the entry for 'memory' node we saw in point (2)

(4). To further confirm my findings, I added some print messages to the 
kernel (inside function 'arm64_memblock_init' in 'arch/arm64/mm/init.c' 
file):

[    0.000000] inside arm64_memblock_init, memstart_addr = 4000000000, 
ARM64_MEMSTART_ALIGN = 40000000, linear_region_size = 800000000000, 
PAGE_OFFSET = ffff800000000000, BIT(VA_BITS - 1) = 800000000000

It also confirms that memstart_addr = PHYS_OFFSET = 0x4000000000

So, I am not able to reproduce this issue at my side and also cannot see 
the issue with the vmcore generated at my end.

Thanks,
Bhupesh

> Signed-off-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
> ---
>   kexec/arch/arm64/kexec-arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 100 insertions(+)
> 
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 62f3758..d9e65fb 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -14,6 +14,8 @@
>   #include <sys/stat.h>
>   #include <linux/elf-em.h>
>   #include <elf.h>
> +#include <sys/mman.h>
> +#include <fcntl.h>
> 
>   #include "kexec.h"
>   #include "kexec-arm64.h"
> @@ -33,6 +35,12 @@
>   #define PROP_ELFCOREHDR "linux,elfcorehdr"
>   #define PROP_USABLE_MEM_RANGE "linux,usable-memory-range"
> 
> +#define DEV_MEM "/dev/mem"
> +
> +#define ALIGN_MASK(x, y) (((x) + (y)) & ~(y))
> +#define ALIGN(x, y)    ALIGN_MASK(x, (y) - 1)
> +#define BUFSIZE  (256)
> +
>   /* Global varables the core kexec routines expect. */
> 
>   unsigned char reuse_initrd;
> @@ -660,6 +668,96 @@ unsigned long phys_to_virt(struct crash_elf_info *elf_info,
>          return v;
>   }
> 
> +static uint64_t get_kernel_paddr(void)
> +{
> +       uint64_t start;
> +
> +       if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
> +               dbgprintf("kernel load physical addr start = 0x%" PRIu64 "\n",
> +                       start);
> +               return start;
> +       }
> +
> +       fprintf(stderr, "Cannot determine kernel physical load addr\n");
> +       exit(3);
> +}
> +
> +static uint64_t get_kimage_voffset(void)
> +{
> +       uint64_t kern_vaddr_start;
> +       uint64_t kern_paddr_start;
> +
> +       kern_paddr_start = get_kernel_paddr();
> +       kern_vaddr_start = get_kernel_sym("_text");
> +
> +       return kern_vaddr_start - kern_paddr_start;
> +}
> +
> +static uint64_t kimg_to_phys(uint64_t vaddr)
> +{
> +       return vaddr - get_kimage_voffset();
> +}
> +
> +static void *map_addr(int fd, unsigned long size, off_t offset)
> +{
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = offset & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
> +       void *result;
> +
> +       result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
> +       if (result == MAP_FAILED) {
> +               fprintf(stderr,
> +                       "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
> +                       (unsigned long long)offset, size, strerror(errno));
> +               exit(5);
> +       }
> +       return result + map_offset;
> +}
> +
> +static void unmap_addr(void *addr, unsigned long size)
> +{
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
> +       int ret;
> +
> +       addr -= map_offset;
> +
> +       ret = munmap(addr, len);
> +       if (ret < 0) {
> +               fprintf(stderr, "munmap failed: %s\n",
> +                       strerror(errno));
> +               exit(6);
> +       }
> +}
> +
> +static void init_phys_offset(void)
> +{
> +       int fd;
> +       uint64_t phys_offset;
> +       uint64_t memstart_addr_paddr;
> +       void *memstart_addr_vaddr;
> +
> +       memstart_addr_paddr = kimg_to_phys(get_kernel_sym("memstart_addr"));
> +
> +       fd = open(DEV_MEM, O_RDONLY);
> +       if (fd < 0) {
> +               fprintf(stderr, "Cannot open " DEV_MEM ": %s\n",
> +                       strerror(errno));
> +               exit(3);
> +       }
> +
> +       memstart_addr_vaddr = map_addr(fd,
> +                       sizeof(memstart_addr_paddr), memstart_addr_paddr);
> +
> +       phys_offset = *(uint64_t *)memstart_addr_vaddr;
> +       unmap_addr(memstart_addr_vaddr, sizeof(memstart_addr_paddr));
> +       close(fd);
> +
> +       set_phys_offset(phys_offset);
> +}
> +
>   /**
>    * add_segment - Use virt_to_phys when loading elf files.
>    */
> @@ -731,6 +829,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>          unsigned int count;
>          int result;
> 
> +       init_phys_offset();
> +
>          result = get_memory_ranges_iomem(array, &count);
> 
>          *range = result ? NULL : array;
> --
> 1.8.3.1
> 
> 
> 
> 
> 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


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

RE: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

Hi Bhupesh,

I am not sure what differences between our environments, but I guess you didn't enable ACPI on your board.  Since ARM64's kdump can't work without the below patch if ACPI is enabled.

https://patchwork.kernel.org/patch/10361761/

My kernel's .config is based on " arch/arm64/configs/defconfig", but made some private changes. If you are using a public board to test, could you share your kernel .config, then I can compare it with mine.

To simplify our discussion, I ignored the above patch and my kexec-tools patch temporarily, used the original kexec-tools(2.0.17) and kernel 4.17-rc6 to do test.
kexec-tools is without any changes,  just added a pr_notice into the end of start_kerne() in kernel, and repeated your step 1 and 4(simplified version), I can see a mismatch between memstart_adddr in kernel and phys_offset.

(1) kexec -p arch/arm64/boot/Image.gz -d (Don't need other arguments here, since we only need debug messages)

# kexec -p arch/arm64/boot/Image.gz -d > kdumplog  2>&1
# grep phys_offset kdumplog

image_arm64_load: phys_offset:    0000000000200000

# head -1 /proc/iomem
00200000-0021ffff : reserved

We can see that phys_offset is identical with the first iomem node range, this is what the current code wants.

(2) ]# dmesg | grep memstart_addr
[    0.006235] memstart_addr is 0x0

memstart_addr is 0, not phys_offset.

I also listed my kexec-tools and kernel version in details for reference.

Kexec-tools version: 2.0.17.git, without any changes:
The last commit is :

commit 0481e9ed61ef80b3d851bb96b0c70a3d4a112c8b
Author: Geoff Levand <geoff@infradead.org>
Date:   Wed Apr 11 11:30:48 2018 -0700

    kexec: Add --no-checks option

Kernel version: 4.17-rc6, with the below git diff to print memstart_addr:

The last commit is:

commit 771c577c23bac90597c685971d7297ea00f99d11
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun May 20 15:31:38 2018 -0700

    Linux 4.17-rc6

git diff
diff --git a/init/main.c b/init/main.c
index fd37315..61c80ca 100644
--- a/init/main.c
+++ b/init/main.c
@@ -733,6 +733,7 @@ asmlinkage __visible void __init start_kernel(void)
                efi_free_boot_services();
        }

+       pr_notice("memstart_addr is 0x%llx\n", memstart_addr);
        /* Do the rest non-__init'ed, we're now alive */
        rest_init();


Thanks!
Yanjiang

-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
Sent: 2018年5月25日 17:45
To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>; kexec@lists.infradead.org
Cc: jinyanjiang@gmail.com; horms@verge.net.au; Baoquan He <bhe@redhat.com>
Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

Thanks Bao for adding me to the Cc list.

Hi Yanjiang Jin,

Thanks for the patch. I have a few queries, please see them inline:

On 05/11/2018 11:30 AM, Yanjiang Jin wrote:
> Now, according to the kernel's memory.h, converting a virtual address
> to a physical address should be done like below:
>
>          phys_addr_t __x = (phys_addr_t)(x); \
>          __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :
> \
>                                   (__x - kimage_voffset); })
>
> We just set PHYS_OFFSET as the start address of the first usable
> memory block in SYSTEM RAM before, but it is defined in kernel as below:
>
> define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>
> So we need to calculate PHYS_OFFSET based on some proc nodes.
>
> Without this change, we would get a wrong vmcore.
> Assume that we have a system as below:
>
> Virtual kernel memory layout:
>
>   memory  : 0xffff800000200000 - 0xffff801800000000
>
> The first iomem block:
>
>   00200000-0021ffff : reserved
>
> But in vmcore's elf header, the corresponding memory block as below,
> the last 2M bytes lost due to "iomem" starts from 0x200000.
>
>    Type     VirtAddr
>    LOAD     0xffff80017fe00000
>
> If an application, for example, vmcore-dmesg, wants to access the
> kernel symbol which is located in the last 2M address, it would fail
> with the below error:
>
>    "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"

Hmmm, I understand your concern, but I cannot reproduce this issue on apm mustang and qualcomm amberwing boards which I am using.

I have a few comments on this patch but before I jump to the same, can you please help me with the following (so that I have a better understanding of the issue):

- Can you please share the underlying kernel version you are using for reproducing this issue. I used 4.16 arm64 kernel (both _with_ and _without_ kaslr enabled), but I cannot reproduce this issue).

- Also can you please share the output of the 'kexec -p' command with the debug messages enabled (i.e. use -d flag).

- Here are some details of the environment and the logs on apm mustang board with the 4.16 kernel and upstream kexec-tools:

(1)
# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline -d <snip..>

Try gzip decompression.
Try LZMA decompression.
get_memory_ranges_iomem_cb: 0000004000000000 - 00000040001fffff :  reserved
get_memory_ranges_iomem_cb: 0000004000200000 - 00000041fa59ffff : System RAM
get_memory_ranges_iomem_cb: 00000041fa5a0000 - 00000041fa9dffff : reserved
get_memory_ranges_iomem_cb: 00000041fa9e0000 - 00000041ff99ffff : System RAM
get_memory_ranges_iomem_cb: 00000041ff9a0000 - 00000041ff9affff : reserved
get_memory_ranges_iomem_cb: 00000041ff9b0000 - 00000041ff9bffff : System RAM
get_memory_ranges_iomem_cb: 00000041ff9c0000 - 00000041ff9effff : reserved
get_memory_ranges_iomem_cb: 00000041ff9f0000 - 00000041ffffffff : System RAM
elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 00000040efe00000
image_arm64_load: text_offset:    0000000000080000
image_arm64_load: image_size:     0000000001680000
image_arm64_load: phys_offset:    0000004000000000
image_arm64_load: vp_offset:      ffffffffffffffff
image_arm64_load: PE format:      yes
<snip..>

So, phys_offset is '0x0000004000000000' in my case.

Also, the 1st entry in '/proc/iomem' indicated the following 'reserved'
entry:
get_memory_ranges_iomem_cb: 0000004000000000 - 00000040001fffff :  reserved

(2)

# dmesg | grep -i "Virtual kernel" -A 15
[    0.000000] Virtual kernel memory layout:
< snip..>

[    0.000000]     memory  : 0xffff800000000000 - 0xffff800200000000   (
8192 MB)

(3)

# objdump -p vmcore

vmcore:     file format elf64-littleaarch64

Program Header:

<snip..>
     LOAD off    0x0000000022a8190c vaddr 0xffff8001ff9f0000 paddr
0x00000041ff9f0000 align 2**0
          filesz 0x0000000000610000 memsz 0x0000000000610000 flags rwx private flags = 0:

So, the last entry in the vmcore file is also correct, base = 0xffff8001ff9f0000, size = 0x0000000000610000, which implies base + size = 0xFFFF800200000000

This tallies with the entry for 'memory' node we saw in point (2)

(4). To further confirm my findings, I added some print messages to the kernel (inside function 'arm64_memblock_init' in 'arch/arm64/mm/init.c'
file):

[    0.000000] inside arm64_memblock_init, memstart_addr = 4000000000,
ARM64_MEMSTART_ALIGN = 40000000, linear_region_size = 800000000000, PAGE_OFFSET = ffff800000000000, BIT(VA_BITS - 1) = 800000000000

It also confirms that memstart_addr = PHYS_OFFSET = 0x4000000000

So, I am not able to reproduce this issue at my side and also cannot see the issue with the vmcore generated at my end.

Thanks,
Bhupesh

> Signed-off-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
> ---
>   kexec/arch/arm64/kexec-arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 100 insertions(+)
>
> diff --git a/kexec/arch/arm64/kexec-arm64.c
> b/kexec/arch/arm64/kexec-arm64.c index 62f3758..d9e65fb 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -14,6 +14,8 @@
>   #include <sys/stat.h>
>   #include <linux/elf-em.h>
>   #include <elf.h>
> +#include <sys/mman.h>
> +#include <fcntl.h>
>
>   #include "kexec.h"
>   #include "kexec-arm64.h"
> @@ -33,6 +35,12 @@
>   #define PROP_ELFCOREHDR "linux,elfcorehdr"
>   #define PROP_USABLE_MEM_RANGE "linux,usable-memory-range"
>
> +#define DEV_MEM "/dev/mem"
> +
> +#define ALIGN_MASK(x, y) (((x) + (y)) & ~(y))
> +#define ALIGN(x, y)    ALIGN_MASK(x, (y) - 1)
> +#define BUFSIZE  (256)
> +
>   /* Global varables the core kexec routines expect. */
>
>   unsigned char reuse_initrd;
> @@ -660,6 +668,96 @@ unsigned long phys_to_virt(struct crash_elf_info *elf_info,
>          return v;
>   }
>
> +static uint64_t get_kernel_paddr(void) {
> +       uint64_t start;
> +
> +       if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
> +               dbgprintf("kernel load physical addr start = 0x%" PRIu64 "\n",
> +                       start);
> +               return start;
> +       }
> +
> +       fprintf(stderr, "Cannot determine kernel physical load addr\n");
> +       exit(3);
> +}
> +
> +static uint64_t get_kimage_voffset(void) {
> +       uint64_t kern_vaddr_start;
> +       uint64_t kern_paddr_start;
> +
> +       kern_paddr_start = get_kernel_paddr();
> +       kern_vaddr_start = get_kernel_sym("_text");
> +
> +       return kern_vaddr_start - kern_paddr_start; }
> +
> +static uint64_t kimg_to_phys(uint64_t vaddr) {
> +       return vaddr - get_kimage_voffset(); }
> +
> +static void *map_addr(int fd, unsigned long size, off_t offset) {
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = offset & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
> +       void *result;
> +
> +       result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
> +       if (result == MAP_FAILED) {
> +               fprintf(stderr,
> +                       "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
> +                       (unsigned long long)offset, size, strerror(errno));
> +               exit(5);
> +       }
> +       return result + map_offset;
> +}
> +
> +static void unmap_addr(void *addr, unsigned long size) {
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
> +       int ret;
> +
> +       addr -= map_offset;
> +
> +       ret = munmap(addr, len);
> +       if (ret < 0) {
> +               fprintf(stderr, "munmap failed: %s\n",
> +                       strerror(errno));
> +               exit(6);
> +       }
> +}
> +
> +static void init_phys_offset(void)
> +{
> +       int fd;
> +       uint64_t phys_offset;
> +       uint64_t memstart_addr_paddr;
> +       void *memstart_addr_vaddr;
> +
> +       memstart_addr_paddr =
> + kimg_to_phys(get_kernel_sym("memstart_addr"));
> +
> +       fd = open(DEV_MEM, O_RDONLY);
> +       if (fd < 0) {
> +               fprintf(stderr, "Cannot open " DEV_MEM ": %s\n",
> +                       strerror(errno));
> +               exit(3);
> +       }
> +
> +       memstart_addr_vaddr = map_addr(fd,
> +                       sizeof(memstart_addr_paddr),
> + memstart_addr_paddr);
> +
> +       phys_offset = *(uint64_t *)memstart_addr_vaddr;
> +       unmap_addr(memstart_addr_vaddr, sizeof(memstart_addr_paddr));
> +       close(fd);
> +
> +       set_phys_offset(phys_offset);
> +}
> +
>   /**
>    * add_segment - Use virt_to_phys when loading elf files.
>    */
> @@ -731,6 +829,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>          unsigned int count;
>          int result;
>
> +       init_phys_offset();
> +
>          result = get_memory_ranges_iomem(array, &count);
>
>          *range = result ? NULL : array;
> --
> 1.8.3.1
>
>
>
>
> 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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>




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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Pratyush Anand]

Hi Yanjiang,

On Fri, May 11, 2018 at 11:30 AM, Yanjiang Jin
<yanjiang.jin@hxt-semitech.com> wrote:
> Now, according to the kernel's memory.h, converting a virtual address to
> a physical address should be done like below:
>
>         phys_addr_t __x = (phys_addr_t)(x);
> \
>         __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :
> \
>                                  (__x - kimage_voffset); })
>
> We just set PHYS_OFFSET as the start address of the first usable memory
> block in SYSTEM RAM before, but it is defined in kernel as below:
>
> define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>
> So we need to calculate PHYS_OFFSET based on some proc nodes.
>
> Without this change, we would get a wrong vmcore.
> Assume that we have a system as below:
>
> Virtual kernel memory layout:
>
>  memory  : 0xffff800000200000 - 0xffff801800000000
>
> The first iomem block:
>
>  00200000-0021ffff : reserved
>
> But in vmcore's elf header, the corresponding memory block as below,
> the last 2M bytes lost due to "iomem" starts from 0x200000.
>
>   Type     VirtAddr
>   LOAD     0xffff80017fe00000
>
> If an application, for example, vmcore-dmesg, wants to access the
> kernel symbol which is located in the last 2M address, it would
> fail with the below error:
>
>   "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"

I think, fix might not be correct.

Problem is in vmcore-dmesg and that should be fixed and not the kexec.
See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
How symbols are extracted from vmcore.

You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.

You can probably see makedumpfile code, that how to extract
information from "NUMBER".

Once you know the real PHYS_OFFSET (which could have been random if
KASLR is enabled), you can fix the problem you are seeing.

Regards
Pratyush

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

RE: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

Hi Pratyush,

Thanks for your help! but please see my reply inline.

Regards!
Yanjiang

> -----Original Message-----
> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
> Sent: 2018年5月29日 23:04
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au
> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>
> Hi Yanjiang,
>
> On Fri, May 11, 2018 at 11:30 AM, Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
> wrote:
> > Now, according to the kernel's memory.h, converting a virtual address
> > to a physical address should be done like below:
> >
> >         phys_addr_t __x = (phys_addr_t)(x); \
> >         __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :
> > \
> >                                  (__x - kimage_voffset); })
> >
> > We just set PHYS_OFFSET as the start address of the first usable
> > memory block in SYSTEM RAM before, but it is defined in kernel as below:
> >
> > define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
> >
> > So we need to calculate PHYS_OFFSET based on some proc nodes.
> >
> > Without this change, we would get a wrong vmcore.
> > Assume that we have a system as below:
> >
> > Virtual kernel memory layout:
> >
> >  memory  : 0xffff800000200000 - 0xffff801800000000
> >
> > The first iomem block:
> >
> >  00200000-0021ffff : reserved
> >
> > But in vmcore's elf header, the corresponding memory block as below,
> > the last 2M bytes lost due to "iomem" starts from 0x200000.
> >
> >   Type     VirtAddr
> >   LOAD     0xffff80017fe00000
> >
> > If an application, for example, vmcore-dmesg, wants to access the
> > kernel symbol which is located in the last 2M address, it would fail
> > with the below error:
> >
> >   "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
>
> I think, fix might not be correct.
>
> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).

Firstly, for my patch, vmcore-dmesg is just an auxiliary application to help to reproduce this issue. The function, which is to generate vmcore,  is the root cause.

On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone git repo.  Even we want to fix vmcore-dmesg, we still need to send the patch to kexec-tools, right?

Yanjiang

> How symbols are extracted from vmcore.
>
> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
>
> You can probably see makedumpfile code, that how to extract information from
> "NUMBER".

I have seen makedumpfile before, NUMBER(number) is just read a number from vmcore. But as I show before, the root issue is vmcore contains a wrong number, my patch is to fix the vmcore generating issue, we can't read vmcore at this point since we don't have vmcore yet.

NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))

Yanjiang

>
> Once you know the real PHYS_OFFSET (which could have been random if KASLR is
> enabled), you can fix the problem you are seeing.

I have both validated with/without KASLR,  all of them worked well after applying my patch.

Yanjiang
>
> Regards
> Pratyush



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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Pratyush Anand]

Hi Yanjiang,

On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
<yanjiang.jin@hxt-semitech.com> wrote:
> Hi Pratyush,
>
> Thanks for your help! but please see my reply inline.
>

[...]

>> > If an application, for example, vmcore-dmesg, wants to access the
>> > kernel symbol which is located in the last 2M address, it would fail
>> > with the below error:
>> >
>> >   "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
>>
>> I think, fix might not be correct.
>>
>> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
>> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
>
> Firstly, for my patch, vmcore-dmesg is just an auxiliary application to help to reproduce this issue. The function, which is to generate vmcore,  is the root cause.

...and the function which generates vmcore is not the kexec rather the
secondary kernel.

>
> On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone git repo.  Even we want to fix vmcore-dmesg, we still need to send the patch to kexec-tools, right?

Sure. I meant `kexec` application. We have three applications in
kexec-tools. `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is
useless and we are going to get rid off it very soon.]

>
> Yanjiang
>
>> How symbols are extracted from vmcore.
>>
>> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
>>
>> You can probably see makedumpfile code, that how to extract information from
>> "NUMBER".
>
> I have seen makedumpfile before, NUMBER(number) is just read a number from vmcore. But as I show before, the root issue is vmcore contains a wrong number, my patch is to fix the vmcore generating issue, we can't read vmcore at this point since we don't have vmcore yet.

..and IIUC, you were able to reach correctly till the end of secondary
kernel where you tried vmcore-dmesg and then you had issue, right?

How did you conclude that vmcore contains wrong number? It's unlikely,
but if it does then we have problem somewhere in Linux kernel , not
here.

Have you tried to extract "PHYS_OFFSET" from vmcore either in
vmcore-dmesg or in makedumpfile and found it not matching to the value
of "PHYS_OFFSET" from first kernel?

In my understanding flow is like this:

- First kernel will have reserved area for secondary kernel, as well
as for elfcore.
- First kernel will embed all the vmcore information notes into
elfcore (see crash_save_vmcoreinfo_init() ->
arch_crash_save_vmcoreinfo()). Therefore, we will have PHYS_OFFSET,
kimage_voffset and VA_BITS information for first kernel in vmcore,
which is in separate memory and can be read by second kernel
- elfcore will also have notes about all the other physical memory of
first kernel which need to be copied by second kernel.
- Now when crash happens, second kernel should have all the required
info for reading symbols from first kernel's physical memory, no?

>
> NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
>
> Yanjiang
>
>>
>> Once you know the real PHYS_OFFSET (which could have been random if KASLR is
>> enabled), you can fix the problem you are seeing.
>
> I have both validated with/without KASLR,  all of them worked well after applying my patch.

IMHO, even if that works it does not mean that its good a fix. We
should try to find root cause. Moreover, you might not have /dev/mem
available for all the configuration where KASLR is enabled.

Regards
Pratyush

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

RE: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

> -----Original Message-----
> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
> Sent: 2018年5月30日 12:16
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au
> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>
> Hi Yanjiang,
>
> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> wrote:
> > Hi Pratyush,
> >
> > Thanks for your help! but please see my reply inline.
> >
>
> [...]
>
> >> > If an application, for example, vmcore-dmesg, wants to access the
> >> > kernel symbol which is located in the last 2M address, it would
> >> > fail with the below error:
> >> >
> >> >   "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
> >>
> >> I think, fix might not be correct.
> >>
> >> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
> >> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
> >> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
> >
> > Firstly, for my patch, vmcore-dmesg is just an auxiliary application to help to
> reproduce this issue. The function, which is to generate vmcore,  is the root cause.
>
> ...and the function which generates vmcore is not the kexec rather the secondary
> kernel.
>
> >
> > On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone
> git repo.  Even we want to fix vmcore-dmesg, we still need to send the patch to
> kexec-tools, right?
>
> Sure. I meant `kexec` application. We have three applications in kexec-tools.
> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and we are going
> to get rid off it very soon.]
>
> >
> > Yanjiang
> >
> >> How symbols are extracted from vmcore.
> >>
> >> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
> >>
> >> You can probably see makedumpfile code, that how to extract
> >> information from "NUMBER".
> >
> > I have seen makedumpfile before, NUMBER(number) is just read a number
> from vmcore. But as I show before, the root issue is vmcore contains a wrong
> number, my patch is to fix the vmcore generating issue, we can't read vmcore at
> this point since we don't have vmcore yet.
>
> ..and IIUC, you were able to reach correctly till the end of secondary kernel
> where you tried vmcore-dmesg and then you had issue, right?
>
> How did you conclude that vmcore contains wrong number? It's unlikely, but if it
> does then we have problem somewhere in Linux kernel , not here.

Just use "readelf", I can find vmcore contains wrong number:

1. In the first kernel, "dmesg" and grep the last memory node as below, we can see that the end of virtual memory is 0xffff801800000000:

memory  : 0xffff800000200000 - 0xffff801800000000

# head -1 /proc/iomem
00200000-0021ffff : reserved

2. "kexec -p" as usual, then "readelf -a", I got different  "VirtAddr "results with/without my patch(0xffff80017fe00000 and 0xffff800180000000). So the end of virtual memory is wrong without my patch.

(VirtAddr + MemSiz) = (0xffff80017fe00000 + 0x0000001680000000) = 0xFFFF8017FFE00000 != 0xffff801800000000

(VirtAddr + MemSiz) = (0xffff800180000000 + 0x0000001680000000) = 0xffff801800000000;

Since on my environment, iomem starts at 0x20000 as step 1 show, but memstart_addr is 0.

 # readelf -a incorrect-vmcore(Only show the last Program Header here, Without my patch)

ELF Header:
........................

Program Headers:
  Type           Offset             VirtAddr           PhysAddr                 FileSiz            MemSiz              Flags  Align
..............................................................................................................................................................
  LOAD        0x0000000076d40000 0xffff80017fe00000 0x0000000180000000                 0x0000001680000000 0x0000001680000000  RWE    0


# readelf -a correct-vmcore (Only show the last Program Header here, with my patch)

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
.................................

Program Headers:
  Type           Offset             VirtAddr           PhysAddr                  FileSiz            MemSiz              Flags  Align
.................................................................................................................................................................
  LOAD           0x0000000076d40000 0xffff800180000000 0x0000000180000000               0x0000001680000000 0x0000001680000000  RWE    0

Yanjiang

>
> Have you tried to extract "PHYS_OFFSET" from vmcore either in vmcore-dmesg
> or in makedumpfile and found it not matching to the value of "PHYS_OFFSET"
> from first kernel?
>
> In my understanding flow is like this:
>
> - First kernel will have reserved area for secondary kernel, as well as for elfcore.
> - First kernel will embed all the vmcore information notes into elfcore (see
> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()). Therefore, we
> will have PHYS_OFFSET, kimage_voffset and VA_BITS information for first kernel
> in vmcore, which is in separate memory and can be read by second kernel
> - elfcore will also have notes about all the other physical memory of first kernel
> which need to be copied by second kernel.
> - Now when crash happens, second kernel should have all the required info for
> reading symbols from first kernel's physical memory, no?
>
> >
> > NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
> >
> > Yanjiang
> >
> >>
> >> Once you know the real PHYS_OFFSET (which could have been random if
> >> KASLR is enabled), you can fix the problem you are seeing.
> >
> > I have both validated with/without KASLR,  all of them worked well after
> applying my patch.
>
> IMHO, even if that works it does not mean that its good a fix. We should try to
> find root cause. Moreover, you might not have /dev/mem available for all the
> configuration where KASLR is enabled.

Yes, I noticed this before. I plan to send v2 patch once my v1 patch satisfies  you and others.  If " CONFIG_DEVMEM is not set", I will warn the user they may get a wrong vmcore, then back to use the start of "/proc/iomem" as previous if /dev/mem can't find.

Yanjiang
>
> Regards
> Pratyush



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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

> -----Original Message-----
> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
> Sent: 2018年5月30日 12:16
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au
> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>
> Hi Yanjiang,
>
> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> wrote:
> > Hi Pratyush,
> >
> > Thanks for your help! but please see my reply inline.
> >
>
> [...]
>
> >> > If an application, for example, vmcore-dmesg, wants to access the
> >> > kernel symbol which is located in the last 2M address, it would
> >> > fail with the below error:
> >> >
> >> >   "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
> >>
> >> I think, fix might not be correct.
> >>
> >> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
> >> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
> >> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
> >
> > Firstly, for my patch, vmcore-dmesg is just an auxiliary application to help to
> reproduce this issue. The function, which is to generate vmcore,  is the root cause.
>
> ...and the function which generates vmcore is not the kexec rather the secondary
> kernel.
>
> >
> > On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone
> git repo.  Even we want to fix vmcore-dmesg, we still need to send the patch to
> kexec-tools, right?
>
> Sure. I meant `kexec` application. We have three applications in kexec-tools.
> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and we are going
> to get rid off it very soon.]
>
> >
> > Yanjiang
> >
> >> How symbols are extracted from vmcore.
> >>
> >> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
> >>
> >> You can probably see makedumpfile code, that how to extract
> >> information from "NUMBER".
> >
> > I have seen makedumpfile before, NUMBER(number) is just read a number
> from vmcore. But as I show before, the root issue is vmcore contains a wrong
> number, my patch is to fix the vmcore generating issue, we can't read vmcore at
> this point since we don't have vmcore yet.
>
> ..and IIUC, you were able to reach correctly till the end of secondary kernel
> where you tried vmcore-dmesg and then you had issue, right?
>
> How did you conclude that vmcore contains wrong number? It's unlikely, but if it
> does then we have problem somewhere in Linux kernel , not here.

Hi Pratyush,

I think I have found the root cause. In Linux kernel, memblock_mark_nomap() will reserve some memory ranges for EFI, such as EFI_RUNTIME_SERVICES_DATA, EFI_BOOT_SERVICES_DATA. On my environment, the first 2M memory is EFI_RUNTIME_SERVICES_DATA, so it can't be seen in kernel. We also can't set this EFI memory as "reserved", only EFI_ACPI_RECLAIM_MEMORY's memory can be set as "reserved" and seen in kernel.
So I don't think this is a kernel issue, we should fix it in kexec-tools.
Attach kernel's call stack for reference.

drivers/firmware/efi/arm-init.c

efi_init()->reserve_regions()->memblock_mark_nomap()

Hi Bhupesh,

I guess your environment has no EFI support, or the first memblock is not reserved for EFI, so you can't reproduce this issue.

Thanks!
Yanjiang

>
> Have you tried to extract "PHYS_OFFSET" from vmcore either in vmcore-dmesg
> or in makedumpfile and found it not matching to the value of "PHYS_OFFSET"
> from first kernel?
>
> In my understanding flow is like this:
>
> - First kernel will have reserved area for secondary kernel, as well as for elfcore.
> - First kernel will embed all the vmcore information notes into elfcore (see
> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()). Therefore, we
> will have PHYS_OFFSET, kimage_voffset and VA_BITS information for first kernel
> in vmcore, which is in separate memory and can be read by second kernel
> - elfcore will also have notes about all the other physical memory of first kernel
> which need to be copied by second kernel.
> - Now when crash happens, second kernel should have all the required info for
> reading symbols from first kernel's physical memory, no?
>
> >
> > NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
> >
> > Yanjiang
> >
> >>
> >> Once you know the real PHYS_OFFSET (which could have been random if
> >> KASLR is enabled), you can fix the problem you are seeing.
> >
> > I have both validated with/without KASLR,  all of them worked well after
> applying my patch.
>
> IMHO, even if that works it does not mean that its good a fix. We should try to
> find root cause. Moreover, you might not have /dev/mem available for all the
> configuration where KASLR is enabled.
>
> Regards
> Pratyush



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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Bhupesh Sharma]

Hi Yanjiang,

On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
> 
> 
>> -----Original Message-----
>> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
>> Sent: 2018年5月30日 12:16
>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au
>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>>
>> Hi Yanjiang,
>>
>> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>> wrote:
>>> Hi Pratyush,
>>>
>>> Thanks for your help! but please see my reply inline.
>>>
>>
>> [...]
>>
>>>>> If an application, for example, vmcore-dmesg, wants to access the
>>>>> kernel symbol which is located in the last 2M address, it would
>>>>> fail with the below error:
>>>>>
>>>>>    "No program header covering vaddr 0xffff8017ffe90000 found kexec bug?"
>>>>
>>>> I think, fix might not be correct.
>>>>
>>>> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
>>>> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
>>>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
>>>
>>> Firstly, for my patch, vmcore-dmesg is just an auxiliary application to help to
>> reproduce this issue. The function, which is to generate vmcore,  is the root cause.
>>
>> ...and the function which generates vmcore is not the kexec rather the secondary
>> kernel.
>>
>>>
>>> On the other hand, vmcore-dmesg is under kexec-tools, it has no a standalone
>> git repo.  Even we want to fix vmcore-dmesg, we still need to send the patch to
>> kexec-tools, right?
>>
>> Sure. I meant `kexec` application. We have three applications in kexec-tools.
>> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and we are going
>> to get rid off it very soon.]
>>
>>>
>>> Yanjiang
>>>
>>>> How symbols are extracted from vmcore.
>>>>
>>>> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
>>>>
>>>> You can probably see makedumpfile code, that how to extract
>>>> information from "NUMBER".
>>>
>>> I have seen makedumpfile before, NUMBER(number) is just read a number
>> from vmcore. But as I show before, the root issue is vmcore contains a wrong
>> number, my patch is to fix the vmcore generating issue, we can't read vmcore at
>> this point since we don't have vmcore yet.
>>
>> ..and IIUC, you were able to reach correctly till the end of secondary kernel
>> where you tried vmcore-dmesg and then you had issue, right?
>>
>> How did you conclude that vmcore contains wrong number? It's unlikely, but if it
>> does then we have problem somewhere in Linux kernel , not here.
> 
> Hi Pratyush,
> 
> I think I have found the root cause. In Linux kernel, memblock_mark_nomap() will reserve some memory ranges for EFI, such as EFI_RUNTIME_SERVICES_DATA, EFI_BOOT_SERVICES_DATA. On my environment, the first 2M memory is EFI_RUNTIME_SERVICES_DATA, so it can't be seen in kernel. We also can't set this EFI memory as "reserved", only EFI_ACPI_RECLAIM_MEMORY's memory can be set as "reserved" and seen in kernel.
> So I don't think this is a kernel issue, we should fix it in kexec-tools.
> Attach kernel's call stack for reference.
> 
> drivers/firmware/efi/arm-init.c
> 
> efi_init()->reserve_regions()->memblock_mark_nomap()
> 
> Hi Bhupesh,
> 
> I guess your environment has no EFI support, or the first memblock is not reserved for EFI, so you can't reproduce this issue.

Perhaps you missed reading my earlier threads on the subject of 
EFI_ACPI_RECLAIM_MEMORY regions being mapped as NOMAP and how it causes 
the crashkernel to panic (please go through [1]).

As of now we haven't found a acceptable-to-all solution for the issue 
and it needs to be fixed in the 'kexec-tools' with a minor fix in the 
kernel side as well.

So, coming back to my environment details, it has both EFI support as 
well as EFI ACPI RECLAIM regions.

However we may be hitting a special case in your environment, so I 
think before we can discuss your patch further (as both Pratyush and 
myself have concerns with the same), would request you to share the 
following:

- output of kernel dmesg with 'efi=debug' added in the bootargs (which 
will help us see how the memblocks are marked at your setup - I am 
specifically interested in the logs after the line 'Processing EFI 
memory map'),
- if you are using a public arm64 platform maybe you can share the 
CONFIG file,
- output of 'cat /proc/iomem'

[1] https://www.spinics.net/lists/arm-kernel/msg616632.html

Thanks,
Bhupesh

>> Have you tried to extract "PHYS_OFFSET" from vmcore either in vmcore-dmesg
>> or in makedumpfile and found it not matching to the value of "PHYS_OFFSET"
>> from first kernel?
>>
>> In my understanding flow is like this:
>>
>> - First kernel will have reserved area for secondary kernel, as well as for elfcore.
>> - First kernel will embed all the vmcore information notes into elfcore (see
>> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()). Therefore, we
>> will have PHYS_OFFSET, kimage_voffset and VA_BITS information for first kernel
>> in vmcore, which is in separate memory and can be read by second kernel
>> - elfcore will also have notes about all the other physical memory of first kernel
>> which need to be copied by second kernel.
>> - Now when crash happens, second kernel should have all the required info for
>> reading symbols from first kernel's physical memory, no?
>>
>>>
>>> NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
>>>
>>> Yanjiang
>>>
>>>>
>>>> Once you know the real PHYS_OFFSET (which could have been random if
>>>> KASLR is enabled), you can fix the problem you are seeing.
>>>
>>> I have both validated with/without KASLR,  all of them worked well after
>> applying my patch.
>>
>> IMHO, even if that works it does not mean that its good a fix. We should try to
>> find root cause. Moreover, you might not have /dev/mem available for all the
>> configuration where KASLR is enabled.
>>
>> Regards
>> Pratyush
> 
> 
> 
> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> Sent: 2018年5月30日 16:39
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>; Pratyush Anand
> <pratyush.anand@gmail.com>
> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au;
> Zheng, Joey <yu.zheng@hxt-semitech.com>
> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>
> Hi Yanjiang,
>
> On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
> >
> >
> >> -----Original Message-----
> >> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
> >> Sent: 2018年5月30日 12:16
> >> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> >> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com;
> >> horms@verge.net.au
> >> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
> >>
> >> Hi Yanjiang,
> >>
> >> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
> >> <yanjiang.jin@hxt-semitech.com>
> >> wrote:
> >>> Hi Pratyush,
> >>>
> >>> Thanks for your help! but please see my reply inline.
> >>>
> >>
> >> [...]
> >>
> >>>>> If an application, for example, vmcore-dmesg, wants to access the
> >>>>> kernel symbol which is located in the last 2M address, it would
> >>>>> fail with the below error:
> >>>>>
> >>>>>    "No program header covering vaddr 0xffff8017ffe90000 found kexec
> bug?"
> >>>>
> >>>> I think, fix might not be correct.
> >>>>
> >>>> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
> >>>> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
> >>>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
> >>>
> >>> Firstly, for my patch, vmcore-dmesg is just an auxiliary application
> >>> to help to
> >> reproduce this issue. The function, which is to generate vmcore,  is the root
> cause.
> >>
> >> ...and the function which generates vmcore is not the kexec rather
> >> the secondary kernel.
> >>
> >>>
> >>> On the other hand, vmcore-dmesg is under kexec-tools, it has no a
> >>> standalone
> >> git repo.  Even we want to fix vmcore-dmesg, we still need to send
> >> the patch to kexec-tools, right?
> >>
> >> Sure. I meant `kexec` application. We have three applications in kexec-tools.
> >> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and we
> >> are going to get rid off it very soon.]
> >>
> >>>
> >>> Yanjiang
> >>>
> >>>> How symbols are extracted from vmcore.
> >>>>
> >>>> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
> >>>>
> >>>> You can probably see makedumpfile code, that how to extract
> >>>> information from "NUMBER".
> >>>
> >>> I have seen makedumpfile before, NUMBER(number) is just read a
> >>> number
> >> from vmcore. But as I show before, the root issue is vmcore contains
> >> a wrong number, my patch is to fix the vmcore generating issue, we
> >> can't read vmcore at this point since we don't have vmcore yet.
> >>
> >> ..and IIUC, you were able to reach correctly till the end of
> >> secondary kernel where you tried vmcore-dmesg and then you had issue,
> right?
> >>
> >> How did you conclude that vmcore contains wrong number? It's
> >> unlikely, but if it does then we have problem somewhere in Linux kernel , not
> here.
> >
> > Hi Pratyush,
> >
> > I think I have found the root cause. In Linux kernel, memblock_mark_nomap()
> will reserve some memory ranges for EFI, such as EFI_RUNTIME_SERVICES_DATA,
> EFI_BOOT_SERVICES_DATA. On my environment, the first 2M memory is
> EFI_RUNTIME_SERVICES_DATA, so it can't be seen in kernel. We also can't set
> this EFI memory as "reserved", only EFI_ACPI_RECLAIM_MEMORY's memory can
> be set as "reserved" and seen in kernel.
> > So I don't think this is a kernel issue, we should fix it in kexec-tools.
> > Attach kernel's call stack for reference.
> >
> > drivers/firmware/efi/arm-init.c
> >
> > efi_init()->reserve_regions()->memblock_mark_nomap()
> >
> > Hi Bhupesh,
> >
> > I guess your environment has no EFI support, or the first memblock is not
> reserved for EFI, so you can't reproduce this issue.
>
> Perhaps you missed reading my earlier threads on the subject of
> EFI_ACPI_RECLAIM_MEMORY regions being mapped as NOMAP and how it
> causes the crashkernel to panic (please go through [1]).
>
> As of now we haven't found a acceptable-to-all solution for the issue and it needs
> to be fixed in the 'kexec-tools' with a minor fix in the kernel side as well.
>
> So, coming back to my environment details, it has both EFI support as well as EFI
> ACPI RECLAIM regions.
>
> However we may be hitting a special case in your environment, so I think before
> we can discuss your patch further (as both Pratyush and myself have concerns
> with the same), would request you to share the
> following:
>
> - output of kernel dmesg with 'efi=debug' added in the bootargs (which will help
> us see how the memblocks are marked at your setup - I am specifically interested
> in the logs after the line 'Processing EFI memory map'),

I made more investigation on my board.   I believe that the firmware design leads this differences between our environments:

My firmware defines the first two EFI block as below:

Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]

But EFI API won't return the "EfiReservedMemType" memory to Linux kernel for security reasons, so kernel can't get any info about the first mem block, kernel can only see region2 as below:

efi: Processing EFI memory map:
efi:   0x000000200000-0x00000021ffff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]

# head -1 /proc/iomem
00200000-0021ffff : reserved

There are many EfiReservedMemType regions in ARM64's firmware if it supports TrustZone, but if a firmware doesn't put this type of memory region at the start of physical memory, this error wouldn't happen. I don't think firmware has error since it can reserve any memory regions, we'd better update kexec-tools.
Anyway, read memstart_addr from /dev/mem can always get  a correct value if DEVMEM is defined.

Regards!
Yanjiang

> - if you are using a public arm64 platform maybe you can share the CONFIG file,
> - output of 'cat /proc/iomem'
>
> [1] https://www.spinics.net/lists/arm-kernel/msg616632.html
>
> Thanks,
> Bhupesh
>
> >> Have you tried to extract "PHYS_OFFSET" from vmcore either in
> >> vmcore-dmesg or in makedumpfile and found it not matching to the value of
> "PHYS_OFFSET"
> >> from first kernel?
> >>
> >> In my understanding flow is like this:
> >>
> >> - First kernel will have reserved area for secondary kernel, as well as for
> elfcore.
> >> - First kernel will embed all the vmcore information notes into
> >> elfcore (see
> >> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()).
> >> Therefore, we will have PHYS_OFFSET, kimage_voffset and VA_BITS
> >> information for first kernel in vmcore, which is in separate memory
> >> and can be read by second kernel
> >> - elfcore will also have notes about all the other physical memory of
> >> first kernel which need to be copied by second kernel.
> >> - Now when crash happens, second kernel should have all the required
> >> info for reading symbols from first kernel's physical memory, no?
> >>
> >>>
> >>> NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
> >>>
> >>> Yanjiang
> >>>
> >>>>
> >>>> Once you know the real PHYS_OFFSET (which could have been random if
> >>>> KASLR is enabled), you can fix the problem you are seeing.
> >>>
> >>> I have both validated with/without KASLR,  all of them worked well
> >>> after
> >> applying my patch.
> >>
> >> IMHO, even if that works it does not mean that its good a fix. We
> >> should try to find root cause. Moreover, you might not have /dev/mem
> >> available for all the configuration where KASLR is enabled.
> >>
> >> Regards
> >> Pratyush
> >
> >
> >
> > 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.
> >
> >




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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Bhupesh Sharma]

On 05/30/2018 03:50 PM, Jin, Yanjiang wrote:
> 
> 
>> -----Original Message-----
>> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
>> Sent: 2018年5月30日 16:39
>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>; Pratyush Anand
>> <pratyush.anand@gmail.com>
>> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au;
>> Zheng, Joey <yu.zheng@hxt-semitech.com>
>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>>
>> Hi Yanjiang,
>>
>> On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
>>>> Sent: 2018年5月30日 12:16
>>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>>>> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com;
>>>> horms@verge.net.au
>>>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>>>>
>>>> Hi Yanjiang,
>>>>
>>>> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
>>>> <yanjiang.jin@hxt-semitech.com>
>>>> wrote:
>>>>> Hi Pratyush,
>>>>>
>>>>> Thanks for your help! but please see my reply inline.
>>>>>
>>>>
>>>> [...]
>>>>
>>>>>>> If an application, for example, vmcore-dmesg, wants to access the
>>>>>>> kernel symbol which is located in the last 2M address, it would
>>>>>>> fail with the below error:
>>>>>>>
>>>>>>>     "No program header covering vaddr 0xffff8017ffe90000 found kexec
>> bug?"
>>>>>>
>>>>>> I think, fix might not be correct.
>>>>>>
>>>>>> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
>>>>>> See here (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
>>>>>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
>>>>>
>>>>> Firstly, for my patch, vmcore-dmesg is just an auxiliary application
>>>>> to help to
>>>> reproduce this issue. The function, which is to generate vmcore,  is the root
>> cause.
>>>>
>>>> ...and the function which generates vmcore is not the kexec rather
>>>> the secondary kernel.
>>>>
>>>>>
>>>>> On the other hand, vmcore-dmesg is under kexec-tools, it has no a
>>>>> standalone
>>>> git repo.  Even we want to fix vmcore-dmesg, we still need to send
>>>> the patch to kexec-tools, right?
>>>>
>>>> Sure. I meant `kexec` application. We have three applications in kexec-tools.
>>>> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and we
>>>> are going to get rid off it very soon.]
>>>>
>>>>>
>>>>> Yanjiang
>>>>>
>>>>>> How symbols are extracted from vmcore.
>>>>>>
>>>>>> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
>>>>>>
>>>>>> You can probably see makedumpfile code, that how to extract
>>>>>> information from "NUMBER".
>>>>>
>>>>> I have seen makedumpfile before, NUMBER(number) is just read a
>>>>> number
>>>> from vmcore. But as I show before, the root issue is vmcore contains
>>>> a wrong number, my patch is to fix the vmcore generating issue, we
>>>> can't read vmcore at this point since we don't have vmcore yet.
>>>>
>>>> ..and IIUC, you were able to reach correctly till the end of
>>>> secondary kernel where you tried vmcore-dmesg and then you had issue,
>> right?
>>>>
>>>> How did you conclude that vmcore contains wrong number? It's
>>>> unlikely, but if it does then we have problem somewhere in Linux kernel , not
>> here.
>>>
>>> Hi Pratyush,
>>>
>>> I think I have found the root cause. In Linux kernel, memblock_mark_nomap()
>> will reserve some memory ranges for EFI, such as EFI_RUNTIME_SERVICES_DATA,
>> EFI_BOOT_SERVICES_DATA. On my environment, the first 2M memory is
>> EFI_RUNTIME_SERVICES_DATA, so it can't be seen in kernel. We also can't set
>> this EFI memory as "reserved", only EFI_ACPI_RECLAIM_MEMORY's memory can
>> be set as "reserved" and seen in kernel.
>>> So I don't think this is a kernel issue, we should fix it in kexec-tools.
>>> Attach kernel's call stack for reference.
>>>
>>> drivers/firmware/efi/arm-init.c
>>>
>>> efi_init()->reserve_regions()->memblock_mark_nomap()
>>>
>>> Hi Bhupesh,
>>>
>>> I guess your environment has no EFI support, or the first memblock is not
>> reserved for EFI, so you can't reproduce this issue.
>>
>> Perhaps you missed reading my earlier threads on the subject of
>> EFI_ACPI_RECLAIM_MEMORY regions being mapped as NOMAP and how it
>> causes the crashkernel to panic (please go through [1]).
>>
>> As of now we haven't found a acceptable-to-all solution for the issue and it needs
>> to be fixed in the 'kexec-tools' with a minor fix in the kernel side as well.
>>
>> So, coming back to my environment details, it has both EFI support as well as EFI
>> ACPI RECLAIM regions.
>>
>> However we may be hitting a special case in your environment, so I think before
>> we can discuss your patch further (as both Pratyush and myself have concerns
>> with the same), would request you to share the
>> following:
>>
>> - output of kernel dmesg with 'efi=debug' added in the bootargs (which will help
>> us see how the memblocks are marked at your setup - I am specifically interested
>> in the logs after the line 'Processing EFI memory map'),
> 
> I made more investigation on my board.   I believe that the firmware design leads this differences between our environments:
> 
> My firmware defines the first two EFI block as below:
> 
> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
> 
> But EFI API won't return the "EfiReservedMemType" memory to Linux kernel for security reasons, so kernel can't get any info about the first mem block, kernel can only see region2 as below:
> 
> efi: Processing EFI memory map:
> efi:   0x000000200000-0x00000021ffff [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]
> 
> # head -1 /proc/iomem
> 00200000-0021ffff : reserved

I have the same case on boards at my end:

# head -1 /proc/iomem
00200000-0021ffff : reserved

# dmesg | grep -i "Processing EFI memory map" -A 5
[    0.000000] efi: Processing EFI memory map:
[    0.000000] efi:   0x000000200000-0x00000021ffff [Runtime Data 
|RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000000400000-0x0000005fffff [ACPI Memory NVS 
|   |  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x000000800000-0x00000081ffff [ACPI Memory NVS 
|   |  |  |  |  |  |  |   |  |  |  |UC]
[    0.000000] efi:   0x000000820000-0x000001600fff [Conventional 
Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000] efi:   0x000001601000-0x0000027fffff [Loader Data 
|   |  |  |  |  |  |  |   |WB|WT|WC|UC]

So, no your environment is not a special one (as I also use ATF as the 
EL3 boot firmware), see more below ..

> There are many EfiReservedMemType regions in ARM64's firmware if it supports TrustZone, but if a firmware doesn't put this type of memory region at the start of physical memory, this error wouldn't happen. I don't think firmware has error since it can reserve any memory regions, we'd better update kexec-tools.
> Anyway, read memstart_addr from /dev/mem can always get  a correct value if DEVMEM is defined.

.. At my side with the latest upstream kernel (with commit 
f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a reverted to allow crashkernel 
to boot while accessing ACPI tables) and latest upstream kexec-tools, I 
can boot the crashkernel properly, collect the vmcore properly and 
analyze the crash dump via tools like gdb and crash also.

So, I would try to also use the vmcore-dmesg tool and see if I get any 
issues with the same. Till then you can try and see if there are any 
other obvious differences in your environment which might be causing 
this issue at your end.

Thanks,
Bhupesh


>> - if you are using a public arm64 platform maybe you can share the CONFIG file,
>> - output of 'cat /proc/iomem'
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg616632.html
>>
>> Thanks,
>> Bhupesh
>>
>>>> Have you tried to extract "PHYS_OFFSET" from vmcore either in
>>>> vmcore-dmesg or in makedumpfile and found it not matching to the value of
>> "PHYS_OFFSET"
>>>> from first kernel?
>>>>
>>>> In my understanding flow is like this:
>>>>
>>>> - First kernel will have reserved area for secondary kernel, as well as for
>> elfcore.
>>>> - First kernel will embed all the vmcore information notes into
>>>> elfcore (see
>>>> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()).
>>>> Therefore, we will have PHYS_OFFSET, kimage_voffset and VA_BITS
>>>> information for first kernel in vmcore, which is in separate memory
>>>> and can be read by second kernel
>>>> - elfcore will also have notes about all the other physical memory of
>>>> first kernel which need to be copied by second kernel.
>>>> - Now when crash happens, second kernel should have all the required
>>>> info for reading symbols from first kernel's physical memory, no?
>>>>
>>>>>
>>>>> NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
>>>>>
>>>>> Yanjiang
>>>>>
>>>>>>
>>>>>> Once you know the real PHYS_OFFSET (which could have been random if
>>>>>> KASLR is enabled), you can fix the problem you are seeing.
>>>>>
>>>>> I have both validated with/without KASLR,  all of them worked well
>>>>> after
>>>> applying my patch.
>>>>
>>>> IMHO, even if that works it does not mean that its good a fix. We
>>>> should try to find root cause. Moreover, you might not have /dev/mem
>>>> available for all the configuration where KASLR is enabled.
>>>>
>>>> Regards
>>>> Pratyush
>>>
>>>
>>>
>>> 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.
>>>
>>>
> 
> 
> 
> 
> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [此邮件可能存在风险] Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> Sent: 2018年5月30日 23:56
> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>; Pratyush Anand
> <pratyush.anand@gmail.com>
> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com; horms@verge.net.au;
> Zheng, Joey <yu.zheng@hxt-semitech.com>
> Subject: [此邮件可能存在风险] Re: [PATCH] arm64: update PHYS_OFFSET to
> conform to kernel
>
> On 05/30/2018 03:50 PM, Jin, Yanjiang wrote:
> >
> >
> >> -----Original Message-----
> >> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> >> Sent: 2018年5月30日 16:39
> >> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>; Pratyush Anand
> >> <pratyush.anand@gmail.com>
> >> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com;
> >> horms@verge.net.au; Zheng, Joey <yu.zheng@hxt-semitech.com>
> >> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
> >>
> >> Hi Yanjiang,
> >>
> >> On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Pratyush Anand [mailto:pratyush.anand@gmail.com]
> >>>> Sent: 2018年5月30日 12:16
> >>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> >>>> Cc: kexec@lists.infradead.org; jinyanjiang@gmail.com;
> >>>> horms@verge.net.au
> >>>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
> >>>>
> >>>> Hi Yanjiang,
> >>>>
> >>>> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
> >>>> <yanjiang.jin@hxt-semitech.com>
> >>>> wrote:
> >>>>> Hi Pratyush,
> >>>>>
> >>>>> Thanks for your help! but please see my reply inline.
> >>>>>
> >>>>
> >>>> [...]
> >>>>
> >>>>>>> If an application, for example, vmcore-dmesg, wants to access
> >>>>>>> the kernel symbol which is located in the last 2M address, it
> >>>>>>> would fail with the below error:
> >>>>>>>
> >>>>>>>     "No program header covering vaddr 0xffff8017ffe90000 found
> >>>>>>> kexec
> >> bug?"
> >>>>>>
> >>>>>> I think, fix might not be correct.
> >>>>>>
> >>>>>> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
> >>>>>> See here
> >>>>>> (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
> >>>>>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
> >>>>>
> >>>>> Firstly, for my patch, vmcore-dmesg is just an auxiliary
> >>>>> application to help to
> >>>> reproduce this issue. The function, which is to generate vmcore,
> >>>> is the root
> >> cause.
> >>>>
> >>>> ...and the function which generates vmcore is not the kexec rather
> >>>> the secondary kernel.
> >>>>
> >>>>>
> >>>>> On the other hand, vmcore-dmesg is under kexec-tools, it has no a
> >>>>> standalone
> >>>> git repo.  Even we want to fix vmcore-dmesg, we still need to send
> >>>> the patch to kexec-tools, right?
> >>>>
> >>>> Sure. I meant `kexec` application. We have three applications in kexec-tools.
> >>>> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and
> >>>> we are going to get rid off it very soon.]
> >>>>
> >>>>>
> >>>>> Yanjiang
> >>>>>
> >>>>>> How symbols are extracted from vmcore.
> >>>>>>
> >>>>>> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
> >>>>>>
> >>>>>> You can probably see makedumpfile code, that how to extract
> >>>>>> information from "NUMBER".
> >>>>>
> >>>>> I have seen makedumpfile before, NUMBER(number) is just read a
> >>>>> number
> >>>> from vmcore. But as I show before, the root issue is vmcore
> >>>> contains a wrong number, my patch is to fix the vmcore generating
> >>>> issue, we can't read vmcore at this point since we don't have vmcore yet.
> >>>>
> >>>> ..and IIUC, you were able to reach correctly till the end of
> >>>> secondary kernel where you tried vmcore-dmesg and then you had
> >>>> issue,
> >> right?
> >>>>
> >>>> How did you conclude that vmcore contains wrong number? It's
> >>>> unlikely, but if it does then we have problem somewhere in Linux
> >>>> kernel , not
> >> here.
> >>>
> >>> Hi Pratyush,
> >>>
> >>> I think I have found the root cause. In Linux kernel,
> >>> memblock_mark_nomap()
> >> will reserve some memory ranges for EFI, such as
> >> EFI_RUNTIME_SERVICES_DATA, EFI_BOOT_SERVICES_DATA. On my
> environment,
> >> the first 2M memory is EFI_RUNTIME_SERVICES_DATA, so it can't be seen
> >> in kernel. We also can't set this EFI memory as "reserved", only
> >> EFI_ACPI_RECLAIM_MEMORY's memory can be set as "reserved" and seen in
> kernel.
> >>> So I don't think this is a kernel issue, we should fix it in kexec-tools.
> >>> Attach kernel's call stack for reference.
> >>>
> >>> drivers/firmware/efi/arm-init.c
> >>>
> >>> efi_init()->reserve_regions()->memblock_mark_nomap()
> >>>
> >>> Hi Bhupesh,
> >>>
> >>> I guess your environment has no EFI support, or the first memblock
> >>> is not
> >> reserved for EFI, so you can't reproduce this issue.
> >>
> >> Perhaps you missed reading my earlier threads on the subject of
> >> EFI_ACPI_RECLAIM_MEMORY regions being mapped as NOMAP and how it
> >> causes the crashkernel to panic (please go through [1]).
> >>
> >> As of now we haven't found a acceptable-to-all solution for the issue
> >> and it needs to be fixed in the 'kexec-tools' with a minor fix in the kernel side
> as well.
> >>
> >> So, coming back to my environment details, it has both EFI support as
> >> well as EFI ACPI RECLAIM regions.
> >>
> >> However we may be hitting a special case in your environment, so I
> >> think before we can discuss your patch further (as both Pratyush and
> >> myself have concerns with the same), would request you to share the
> >> following:
> >>
> >> - output of kernel dmesg with 'efi=debug' added in the bootargs
> >> (which will help us see how the memblocks are marked at your setup -
> >> I am specifically interested in the logs after the line 'Processing
> >> EFI memory map'),
> >
> > I made more investigation on my board.   I believe that the firmware design
> leads this differences between our environments:
> >
> > My firmware defines the first two EFI block as below:
> >
> > Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
> > Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
> >
> > But EFI API won't return the "EfiReservedMemType" memory to Linux kernel
> for security reasons, so kernel can't get any info about the first mem block, kernel
> can only see region2 as below:
> >
> > efi: Processing EFI memory map:
> > efi:   0x000000200000-0x00000021ffff [Runtime Data       |RUN|  |  |  |  |  |  |
> |WB|WT|WC|UC]
> >
> > # head -1 /proc/iomem
> > 00200000-0021ffff : reserved
>
> I have the same case on boards at my end:
>
> # head -1 /proc/iomem
> 00200000-0021ffff : reserved
>
> # dmesg | grep -i "Processing EFI memory map" -A 5
> [    0.000000] efi: Processing EFI memory map:
> [    0.000000] efi:   0x000000200000-0x00000021ffff [Runtime Data
> |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000] efi:   0x000000400000-0x0000005fffff [ACPI Memory NVS
> |   |  |  |  |  |  |  |   |  |  |  |UC]
> [    0.000000] efi:   0x000000800000-0x00000081ffff [ACPI Memory NVS
> |   |  |  |  |  |  |  |   |  |  |  |UC]
> [    0.000000] efi:   0x000000820000-0x000001600fff [Conventional
> Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000] efi:   0x000001601000-0x0000027fffff [Loader Data
> |   |  |  |  |  |  |  |   |WB|WT|WC|UC]
>
> So, no your environment is not a special one (as I also use ATF as the
> EL3 boot firmware), see more below ..
>
> > There are many EfiReservedMemType regions in ARM64's firmware if it
> supports TrustZone, but if a firmware doesn't put this type of memory region at
> the start of physical memory, this error wouldn't happen. I don't think firmware
> has error since it can reserve any memory regions, we'd better update kexec-
> tools.
> > Anyway, read memstart_addr from /dev/mem can always get  a correct value if
> DEVMEM is defined.
>
> .. At my side with the latest upstream kernel (with commit
> f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a reverted to allow crashkernel to
> boot while accessing ACPI tables) and latest upstream kexec-tools, I can boot the
> crashkernel properly, collect the vmcore properly and analyze the crash dump via
> tools like gdb and crash also.
>
> So, I would try to also use the vmcore-dmesg tool and see if I get any issues with
> the same. Till then you can try and see if there are any other obvious differences
> in your environment which might be causing this issue at your end.

Hi Bhupesh,

Your patience is much appreciated.  I will do more investigating both in kernel and kexec-tools.

Thanks!
Yanjiang
>
> Thanks,
> Bhupesh
>
>
> >> - if you are using a public arm64 platform maybe you can share the
> >> CONFIG file,
> >> - output of 'cat /proc/iomem'
> >>
> >> [1] https://www.spinics.net/lists/arm-kernel/msg616632.html
> >>
> >> Thanks,
> >> Bhupesh
> >>
> >>>> Have you tried to extract "PHYS_OFFSET" from vmcore either in
> >>>> vmcore-dmesg or in makedumpfile and found it not matching to the
> >>>> value of
> >> "PHYS_OFFSET"
> >>>> from first kernel?
> >>>>
> >>>> In my understanding flow is like this:
> >>>>
> >>>> - First kernel will have reserved area for secondary kernel, as
> >>>> well as for
> >> elfcore.
> >>>> - First kernel will embed all the vmcore information notes into
> >>>> elfcore (see
> >>>> crash_save_vmcoreinfo_init() -> arch_crash_save_vmcoreinfo()).
> >>>> Therefore, we will have PHYS_OFFSET, kimage_voffset and VA_BITS
> >>>> information for first kernel in vmcore, which is in separate memory
> >>>> and can be read by second kernel
> >>>> - elfcore will also have notes about all the other physical memory
> >>>> of first kernel which need to be copied by second kernel.
> >>>> - Now when crash happens, second kernel should have all the
> >>>> required info for reading symbols from first kernel's physical memory, no?
> >>>>
> >>>>>
> >>>>> NUMBER(number) = read_vmcoreinfo_ulong(STR_NUMBER(str_number))
> >>>>>
> >>>>> Yanjiang
> >>>>>
> >>>>>>
> >>>>>> Once you know the real PHYS_OFFSET (which could have been random
> >>>>>> if KASLR is enabled), you can fix the problem you are seeing.
> >>>>>
> >>>>> I have both validated with/without KASLR,  all of them worked well
> >>>>> after
> >>>> applying my patch.
> >>>>
> >>>> IMHO, even if that works it does not mean that its good a fix. We
> >>>> should try to find root cause. Moreover, you might not have
> >>>> /dev/mem available for all the configuration where KASLR is enabled.
> >>>>
> >>>> Regards
> >>>> Pratyush
> >>>
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >
> >
> >
> >
> > 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.
> >
> >




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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec