gmane.linux.kernel.kexec

Kexec corrupts command line in x86-linux-setup.c setup_edd_info()

Dmitry Trikoz — 2012-05-24T17:26:51

Hi,
I've been chasing strange problem with kdump kernel. It was crashing on 
boot without any messages to the console.
Finally I found that kdump kernel command line was corrupt.
Digging down I found the problem in  setup_edd_info() and 
add_edd_entry(). It doesn't check for array size of
real_mode->eddbuf[] and real_mode->edd_mbr_sig_buffer[]
So when it overruns eddbuf[] it corrupts command_line that follows it.

Here is the fix:

--- a/kexec-tools/kexec/arch/i386/x86-linux-setup.c
+++ b/kexec-tools/kexec/arch/i386/x86-linux-setup.c
< at >< at > -275,9 +275,9 < at >< at > static int add_edd_entry(struct 
x86_linux_param_header *real_mode,
                                 "must not be NULL", __FUNCTION__);
                 return -1;
         }
-
-       edd_info = &real_mode->eddbuf[*current_edd];
-       memset(edd_info, 0, sizeof(struct edd_info));
+       if (*current_mbr >= EDD_MBR_SIG_MAX) {
+               return 0;
+       }

         /* extract the device number */
         if (sscanf(basename(sysfs_name), "int13_dev%hhx", &devnum) != 1) {
< at >< at > -293,12 +293,21 < at >< at > static int add_edd_entry(struct 
x86_linux_param_header *real_mode,
                 dbgprintf("EDD Device 0x%x: mbr_sig=0x%x\n", devnum, 
mbr_sig);
         }

+       if (*current_edd >= EDDMAXNR) {
+               return 0;
+       }
+
+       edd_info = &real_mode->eddbuf[*current_edd];
+       memset(edd_info, 0, sizeof(struct edd_info));
+
         /* set the device number */
         edd_info->device = devnum;

         /* set the version */
-       if (file_scanf(sysfs_name, "version", "0x%hhx", &version) != 1)
+       if (file_scanf(sysfs_name, "version", "0x%hhx", &version) != 1) {
+               fprintf(stderr, "sysfs_name %s version file error\n", 
sysfs_name);
                 return -1;
+       }

         edd_info->version = version;

Sincerely,

Dmitry Trikoz

dmitry.trikoz-7+ureL1bLXNBDgjK7y7TUQ< at >public.gmane.org

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Cong Wang — 2012-05-24T01:43:46

Thanks to both of you! :)

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Simon Horman — 2012-05-24T00:31:29

Thanks!

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Suzuki K. Poulose — 2012-05-23T12:50:12

It builds and works fine for me on PPC32. Sample output below.



Thanks
Suzuki



--- Sample output ---

# kexec -p --debug vmlinux.strip
0000000000000000-0000000080000000 : 0
get base memory ranges:1
usable memory rgns size:1 base:8000000 size:8000000
exclude_range sorted exclude_range[0] start:0, end:1617000
setup_memory_ranges memory_range[0] start:1617001, end:30000000
CRASH MEMORY RANGES
0000000000000000-0000000008000000
0000000010000000-0000000080000000
get_crash_notes_per_cpu: crash_notes addr = 305445c
Elf header: p_type = 4, p_offset = 0x305445c p_paddr = 0x305445c p_vaddr 
= 0x0 p_filesz = 0x400 p_memsz = 0x400
vmcoreinfo header: p_type = 4, p_offset = 0x15fa3bc p_paddr = 0x15fa3bc 
p_vaddr = 0x0 p_filesz = 0x1000 p_memsz = 0x1000
Elf header: p_type = 1, p_offset = 0x0 p_paddr = 0x0 p_vaddr = 
0xc0000000 p_filesz = 0x8000000 p_memsz = 0x8000000
Elf header: p_type = 1, p_offset = 0x10000000 p_paddr = 0x10000000 
p_vaddr = 0xffffffff p_filesz = 0x70000000 p_memsz = 0x70000000
Command line after adding elfcorehdr:  elfcorehdr=141860K
Command line after adding elfcorehdr:  elfcorehdr=141860K savemaxmem=2048M
sym: sha256_starts info: 12 other: 00 shndx: 1 value: 0 size: a1c
sym: sha256_starts value: 8a8aa1c addr: 8a8a024
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8a8fae8 addr: 8a8a02a
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8a8fae8 addr: 8a8a02e
sym: sha256_update info: 12 other: 00 shndx: 1 value: 0 size: 5454
sym: sha256_update value: 8a8f454 addr: 8a8a044
sym: sha256_finish info: 12 other: 00 shndx: 1 value: 0 size: 55dc
sym: sha256_finish value: 8a8f5dc addr: 8a8a05c
sym:     memcmp info: 12 other: 00 shndx: 1 value: 0 size: 6e0
sym: memcmp value: 8a8a6e0 addr: 8a8a06c
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fa7c addr: 8a8a07e
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fa7c addr: 8a8a086
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a088
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fa9c addr: 8a8a08e
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fa9c addr: 8a8a092
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a094
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8faac addr: 8a8a09a
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8faac addr: 8a8a09e
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a0ac
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fab2 addr: 8a8a0be
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fab2 addr: 8a8a0c2
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a0c4
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fab4 addr: 8a8a0ca
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fab4 addr: 8a8a0ce
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a0d0
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8a8fae8 addr: 8a8a0d6
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8a8fae8 addr: 8a8a0da
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a0f0
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fab2 addr: 8a8a0fe
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fab2 addr: 8a8a102
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a104
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fac4 addr: 8a8a132
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fac4 addr: 8a8a136
sym:     printf info: 12 other: 00 shndx: 1 value: 0 size: 57c
sym: printf value: 8a8a57c addr: 8a8a13c
sym: setup_arch info: 12 other: 00 shndx: 1 value: 0 size: a0c
sym: setup_arch value: 8a8aa0c addr: 8a8a140
sym: verify_sha256_digest info: 12 other: 00 shndx: 1 value: 0 size: 0
sym: verify_sha256_digest value: 8a8a000 addr: 8a8a144
sym: post_verification_setup_arch info: 12 other: 00 shndx: 1 value: 0 
size: a10
sym: post_verification_setup_arch value: 8a8aa10 addr: 8a8a154
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fad6 addr: 8a8a172
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8a8fad6 addr: 8a8a17a
sym:    putchar info: 12 other: 00 shndx: 1 value: 0 size: a18
sym: putchar value: 8a8aa18 addr: 8a8a1ec
sym:    putchar info: 12 other: 00 shndx: 1 value: 0 size: a18
sym: putchar value: 8a8aa18 addr: 8a8a248
sym:  __lshrdi3 info: 10 other: 00 shndx: 1 value: 0 size: 9e8
sym: __lshrdi3 value: 8a8a9e8 addr: 8a8a370
sym:    putchar info: 12 other: 00 shndx: 1 value: 0 size: a18
sym: putchar value: 8a8aa18 addr: 8a8a508
sym:   vsprintf info: 12 other: 00 shndx: 1 value: 0 size: 168
sym: vsprintf value: 8a8a168 addr: 8a8a5d0
sym:   vsprintf info: 12 other: 00 shndx: 1 value: 0 size: 168
sym: vsprintf value: 8a8a168 addr: 8a8a62c
sym: my_thread_ptr info: 11 other: 00 shndx: 5 value: 0 size: 10
sym: my_thread_ptr value: 8a8fc58 addr: 8a8a836
sym: my_thread_ptr info: 11 other: 00 shndx: 5 value: 0 size: 10
sym: my_thread_ptr value: 8a8fc58 addr: 8a8a83a
sym:      stack info: 11 other: 00 shndx: 5 value: 0 size: 8
sym: stack value: 8a8fc50 addr: 8a8a842
sym:      stack info: 11 other: 00 shndx: 5 value: 0 size: 8
sym: stack value: 8a8fc50 addr: 8a8a846
sym:  purgatory info: 12 other: 00 shndx: 1 value: 0 size: 128
sym: purgatory value: 8a8a128 addr: 8a8a850
sym:  dt_offset info: 11 other: 00 shndx: 5 value: 0 size: c
sym: dt_offset value: 8a8fc54 addr: 8a8a86a
sym:  dt_offset info: 11 other: 00 shndx: 5 value: 0 size: c
sym: dt_offset value: 8a8fc54 addr: 8a8a86e
sym:     kernel info: 11 other: 00 shndx: 5 value: 0 size: 14
sym: kernel value: 8a8fc5c addr: 8a8a886
sym:     kernel info: 11 other: 00 shndx: 5 value: 0 size: 14
sym: kernel value: 8a8fc5c addr: 8a8a88a
sym:     memcpy info: 12 other: 00 shndx: 1 value: 0 size: 6ac
sym: memcpy value: 8a8a6ac addr: 8a8f524
sym: sha256_process info: 12 other: 00 shndx: 1 value: 0 size: ad4
sym: sha256_process value: 8a8aad4 addr: 8a8f538
sym: sha256_process info: 12 other: 00 shndx: 1 value: 0 size: ad4
sym: sha256_process value: 8a8aad4 addr: 8a8f570
sym:     memcpy info: 12 other: 00 shndx: 1 value: 0 size: 6ac
sym: memcpy value: 8a8a6ac addr: 8a8f5c0
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8a8fc08 addr: 8a8f6e6
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8a8fc08 addr: 8a8f6ea
sym: sha256_update info: 12 other: 00 shndx: 1 value: 0 size: 5454
sym: sha256_update value: 8a8f454 addr: 8a8f6f0
sym: sha256_update info: 12 other: 00 shndx: 1 value: 0 size: 5454
sym: sha256_update value: 8a8f454 addr: 8a8f704
Modified cmdline: elfcorehdr=141860K savemaxmem=2048M maxcpus=1
reserve regions: 2
0: offset: 97fe000, size: 2000
1: offset: 8000000, size: a90000
debug.dtb written

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Eric Northup — 2012-05-22T20:53:47

On Mon, May 21, 2012 at 8:53 PM, Yanfei Zhang
<zhangyanfei< at >cn.fujitsu.com> wrote:
[...]
[...]

It's not risky: you just have to make sure that no one else is going
to use the VMCS on your CPU while you're running.  You can disable
preemption and then save the old VMCS pointer from the CPU (see the
VMPTRST instructions).  Load your temporary VMCS pointer, discover
the fields, then restore the original VMCS pointer.  Then re-enable
preemption and you're done.

_______________________________________________
kexec mailing list
kexec< at >lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v2] kexec: simply pass LINUX_REBOOT_CMD_KEXEC to reboot

maximilian attems — 2012-05-22T16:59:47

While trying to port kexec cleanly to klibc,
came across this syscall usage for reboot(2).
Calling reboot directly simplifies the code.

Signed-off-by: maximilian attems <max-U9r9yeDMy7A< at >public.gmane.org>
---
 kexec/kexec-syscall.h |   18 ------------------
 kexec/kexec.c         |    3 ++-
 2 files changed, 2 insertions(+), 19 deletions(-)

v2: keep LINUX_REBOOT_CMD_KEXEC defines, thus no need of <linux/reboot.h>.
    (The packagers don't like linux header deps..)

The next TODO item is to add proper syscall kexec_load() to glibc.
Funnily here klibc has an head start! -maks

diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
index f4df45c..b56cb00 100644
--- a/kexec/kexec-syscall.h
+++ b/kexec/kexec-syscall.h
< at >< at > -5,18 +5,6 < at >< at >
 #include <sys/syscall.h>
 #include <unistd.h>
 
-#defineLINUX_REBOOT_MAGIC10xfee1dead
-#defineLINUX_REBOOT_MAGIC2672274793
-#defineLINUX_REBOOT_MAGIC2A85072278
-#defineLINUX_REBOOT_MAGIC2B369367448
-
-#defineLINUX_REBOOT_CMD_RESTART0x01234567
-#defineLINUX_REBOOT_CMD_HALT0xCDEF0123
-#defineLINUX_REBOOT_CMD_CAD_ON0x89ABCDEF
-#defineLINUX_REBOOT_CMD_CAD_OFF0x00000000
-#defineLINUX_REBOOT_CMD_POWER_OFF0x4321FEDC
-#defineLINUX_REBOOT_CMD_RESTART20xA1B2C3D4
-#define LINUX_REBOOT_CMD_EXEC_KERNEL    0x18273645
 #define LINUX_REBOOT_CMD_KEXEC_OLD0x81726354
 #define LINUX_REBOOT_CMD_KEXEC_OLD20x18263645
 #define LINUX_REBOOT_CMD_KEXEC0x45584543
< at >< at > -70,12 +58,6 < at >< at > static inline long kexec_load(void *entry, unsigned long nr_segments,
 return (long) syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
 }
 
-static inline long kexec_reboot(void)
-{
-return (long) syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC, 0);
-}
-
-
 #define KEXEC_ON_CRASH0x00000001
 #define KEXEC_PRESERVE_CONTEXT0x00000002
 #define KEXEC_ARCH_MASK0xffff0000
diff --git a/kexec/kexec.c b/kexec/kexec.c
index d2d05a8..3572c5b 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
< at >< at > -28,6 +28,7 < at >< at >
 #include <limits.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/reboot.h>
 #include <unistd.h>
 #include <fcntl.h>
 #ifndef _O_BINARY
< at >< at > -822,7 +823,7 < at >< at > static int my_shutdown(void)
  */
 static int my_exec(void)
 {
-kexec_reboot();
+reboot(LINUX_REBOOT_CMD_KEXEC);
 /* I have failed if I make it here */
 fprintf(stderr, "kexec failed: %s\n", 
 strerror(errno));

[PATCH] kexec: simply pass LINUX_REBOOT_CMD_KEXEC to reboot

maximilian attems — 2012-05-22T16:09:58

While trying to port kexec cleanly to klibc,
came across this syscall usage for reboot(2).
Calling reboot directly simplifies the code.

Signed-off-by: maximilian attems <max-U9r9yeDMy7A< at >public.gmane.org>
---
 kexec/kexec-syscall.h |   20 --------------------
 kexec/kexec.c         |    4 +++-
 2 files changed, 3 insertions(+), 21 deletions(-)

The next TODO item is to add proper syscall kexec_load() to glibc.
Funnily here klibc has an head start! -maks

diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
index f4df45c..415fbd7 100644
--- a/kexec/kexec-syscall.h
+++ b/kexec/kexec-syscall.h
< at >< at > -5,22 +5,6 < at >< at >
 #include <sys/syscall.h>
 #include <unistd.h>
 
-#defineLINUX_REBOOT_MAGIC10xfee1dead
-#defineLINUX_REBOOT_MAGIC2672274793
-#defineLINUX_REBOOT_MAGIC2A85072278
-#defineLINUX_REBOOT_MAGIC2B369367448
-
-#defineLINUX_REBOOT_CMD_RESTART0x01234567
-#defineLINUX_REBOOT_CMD_HALT0xCDEF0123
-#defineLINUX_REBOOT_CMD_CAD_ON0x89ABCDEF
-#defineLINUX_REBOOT_CMD_CAD_OFF0x00000000
-#defineLINUX_REBOOT_CMD_POWER_OFF0x4321FEDC
-#defineLINUX_REBOOT_CMD_RESTART20xA1B2C3D4
-#define LINUX_REBOOT_CMD_EXEC_KERNEL    0x18273645
-#define LINUX_REBOOT_CMD_KEXEC_OLD0x81726354
-#define LINUX_REBOOT_CMD_KEXEC_OLD20x18263645
-#define LINUX_REBOOT_CMD_KEXEC0x45584543
-
 #ifndef __NR_kexec_load
 #ifdef __i386__
 #define __NR_kexec_load283
< at >< at > -70,10 +54,6 < at >< at > static inline long kexec_load(void *entry, unsigned long nr_segments,
 return (long) syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
 }
 
-static inline long kexec_reboot(void)
-{
-return (long) syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC, 0);
-}
 
 
 #define KEXEC_ON_CRASH0x00000001
diff --git a/kexec/kexec.c b/kexec/kexec.c
index d2d05a8..ee23b5e 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
< at >< at > -28,6 +28,8 < at >< at >
 #include <limits.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/reboot.h>
+#include <linux/reboot.h>
 #include <unistd.h>
 #include <fcntl.h>
 #ifndef _O_BINARY
< at >< at > -822,7 +824,7 < at >< at > static int my_shutdown(void)
  */
 static int my_exec(void)
 {
-kexec_reboot();
+reboot(LINUX_REBOOT_CMD_KEXEC);
 /* I have failed if I make it here */
 fprintf(stderr, "kexec failed: %s\n", 
 strerror(errno));

Re: Handling spin table in kdump

McClintock Matthew-B29882 — 2012-05-22T15:34:35

I would think option 1 is acceptable. The crash kernel will never
attempt to use the memory outside of the crash kernel region therefore
it does not need to be reserved.

However, I thought we were able to boot SMP into the crash kernel on
our parts... not sure how that effects things (although the maxcpus=1
here is a perfectly acceptable and safer thing to do anyways)

-M

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Yanfei Zhang — 2012-05-22T03:53:27

于 2012年05月22日 02:58, Eric Northup 写道:

We have considered this way, but there are two issues:
1) vmx resource is unique for a single cpu, and it's risky to grab it forcibly
on the environment where kvm module is used, in particular on customer's environment.
To do this safely, kvm support is needed.

2) It highly costs to prepare each cpu to each customer environment to collect
vmcsinfo. After all, there are various environments on our customer's.

Our patch provides a module, so those who doesn't want this feature can just
stop it being auto-loaded when system starts up.

Thanks
Zhang Yanfei


_______________________________________________
kexec mailing list
kexec< at >lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Yanfei Zhang — 2012-05-22T03:40:58

于 2012年05月21日 17:36, Avi Kivity 写道:

We never do this on customer's environment which maybe a host with many guests
running on it. We do this on another environment to reproduce the buggy
situation; or we do this in testing phase on development environment towards
production one on the customer's site.


Both are right.

_______________________________________________
kexec mailing list
kexec< at >lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Eric Northup — 2012-05-21T18:58:51

On Wed, May 16, 2012 at 12:50 AM, zhangyanfei
<zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org> wrote:

Perhaps I'm wrong, but this solution seems much, much more dynamic
than it needs to be.

The VMCS offsets aren't going to change between different boots on the
same CPU, unless perhaps the microcode has been updated.

So you can have the VMCS offset dumping be a manually-loaded module.
Build a database mapping from (CPUID, microcode revision) -> (VMCSINFO).
There's no need for anything beyond the (CPUID, microcode revision) to
be put in the kdump, since your offline processing of a kdump can then
look up the rest.

It means you don't have to interact with the vmx module at all, and
no extra modules or code have to be loaded on the millions of Linux
machines that won't need the functionality.

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Avi Kivity — 2012-05-21T09:36:10

That sounds like a bad idea. Can you explain in what situation it makes
sense for a guest to stop the host (and all other guests running on it)
rather than just restarting the failed services (on the host or other
guests)?


The sadump tool generates a core file with the OS image, right? Can it
not attach the offsets to a note, just like you propose for kdump?

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Yanfei Zhang — 2012-05-21T09:08:06

于 2012年05月21日 16:34, Avi Kivity 写道:

Yes, a guest bug cannot cause a host panic. When heartbeat stops in guest
machine, we could trigger the host dump mechanism to work. This is because
we want to get the status of both host and guest machine at the same time
when heartbeat stops in guest machine. Then we can look for bug reasons
from both host machine's and guest machine's views.

Hmm, you mean we could get VMCS offsets in sadump itself?
But I think if we just export VMCS offsets in kernel, we could use the current
existing dump tools with no or just very tiny change. I think this could be
a more general mechanism than making changes in all kinds of dump tools.

Thanks
Zhang Yanfei

_______________________________________________
kexec mailing list
kexec< at >lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Avi Kivity — 2012-05-21T08:34:16

How can a guest bug cause a host panic?


If the guest caused the problem, there would be no panic; therefore
there was a host bug.


Seems to me the VMCS offsets are OS independent.

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Avi Kivity — 2012-05-20T17:43:54

Do you mean, that a heartbeat failure in the guest lead to host panic?

My expectation is that a problem in the guest will cause the guest to
panic and perhaps produce a dump; the host will remain up.


Shouldn't sadump then expose the VMCS offsets? Perhaps bundling them
into its dump file?

[PATCH] Use HOSTCC for build utilities

Baruch Even — 2012-05-20T00:00:05

Subject: [PATCH] Use HOSTCC for build utilities

bin-to-hex is used during the build and needs to be compiled with the host
compiler to be able to run during the build.

Signed-off-by: Baruch Even <baruch-6P1Dz+XQpLLYtjvyW6yDsg< at >public.gmane.org>
---
 util/Makefile |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/Makefile b/util/Makefile
index 948ee63..82c7407 100644
--- a/util/Makefile
+++ b/util/Makefile
< at >< at > -4,8 +4,8 < at >< at > $(BIN_TO_HEX): $(srcdir)/util/bin-to-hex.c
 < at >$(MKDIR) -p $(< at >D)
 $(LINK.o) $(CFLAGS) -o $< at > $^

-$(BIN_TO_HEX): CC=$(BUILD_CC)
-$(BIN_TO_HEX): CFLAGS=$(BUILD_CFLAGS)
+$(BIN_TO_HEX): CC=$(HOSTCC)
+$(BIN_TO_HEX): CFLAGS=$(HOST_CFLAGS)
 $(BIN_TO_HEX): LDFLAGS=

 dist += util/Makefile util/bin-to-hex.c

Your Mailbox Is Almost Full

Cerda, Weston — 2012-05-18T07:33:42

Your Mailbox Is Almost Full "CLICK HERE<https://docs.google.com/spreadsheet/viewform?formkey=dE1tZWZNRzVyalFmbG9JOUNERzF5enc6MQ>" Update Your MailBox And Increase Your Account. Thanks System Administrator.

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Simon Horman — 2012-05-18T02:59:32

Thank, I don't have any ppc32 (or 64) hardware to test on,
but I did use a cross-compiler to check that it builds.


Applied

Re: makedumpfile memory usage grows with system memory size

HATAYAMA Daisuke — 2012-05-17T00:21:06

From: Atsushi Kumagai <kumagai-atsushi-biTfD1RFvDe45+QrQBaojngSJqDPrsil< at >public.gmane.org>
Subject: Re: makedumpfile memory usage grows with system memory size
Date: Wed, 16 May 2012 17:02:30 +0900

A quick look into the other part of the union---inuse, objects,
froze---to which _mapcount belongs, they appears to be used in SLUB
allocator. The page with PG_slab appears to use the other part to
_mapcount. This means that to decide whether to use _mapcount, it's
necessary to first investigate how SLUB allocator works.

I'll wait for your patch on memory consumption and feedback to
it. I'll also look into possibility of filtering free memory in
constant space on recent kernels.

Thanks.
HATAYAMA, Daisuke

Re: makedumpfile memory usage grows with system memory size

Atsushi Kumagai — 2012-05-16T08:02:30

Hello HATAYAMA-san,

On Mon, 14 May 2012 14:44:28 +0900 (JST)
HATAYAMA Daisuke <d.hatayama-+CUm20s59erQFUHtdCDX3A< at >public.gmane.org> wrote:


Thank you for your investigation, it's very helpful !


I think it's better way to use _mapcount. 
But we don't certainly decide to use _mapcount and even if we decide to use it,
we still have problems to use it.
For example, the upstream kernel(v3.4-rc7) has _mapcount in union, we need
a information to judge whether the found data is _mapcount or not. 
So, more investigation is needed and I think it's too early to send the request
to upstream kernel.

I plan to finish working to reduce memory consumption by the end of June, 
and I will continue to discuss performance issues.
Therefore, the request will be delayed until July or August.


Thanks
Atsushi Kumagai

[PATCH v2 5/5] Documentation: Add ABI entry for sysfs file vmcsinfo and vmcsinfo_maxsize

zhangyanfei — 2012-05-16T07:57:35

We create two new sysfs files, vmcsinfo and vmcsinfo_maxsize. And
here we add an Documentation/ABI entry for them.

Signed-off-by: zhangyanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org>
---
 Documentation/ABI/testing/sysfs-kernel-vmcsinfo |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-vmcsinfo

diff --git a/Documentation/ABI/testing/sysfs-kernel-vmcsinfo b/Documentation/ABI/testing/sysfs-kernel-vmcsinfo
new file mode 100644
index 0000000..adbf866
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-vmcsinfo
< at >< at > -0,0 +1,16 < at >< at >
+What:/sys/kernel/vmcsinfo
+Date:April 2012
+KernelVersion:3.4.0
+Contact:Zhang Yanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org>
+Description
+Shows physical address of VMCSINFO. VMCSINFO contains
+the VMCS revision identifier and encoded offsets of fields
+in VMCS data on Intel processors equipped with the VT
+extensions.
+
+What:/sys/kernel/vmcsinfo_maxsize
+Date:April 2012
+KernelVersion:3.4.0
+Contact:Zhang Yanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org>
+Description
+Shows max size of VMCSINFO.