[PATCH 0/4] Export offsets of VMCS fields as note information for kdump

[PATCH 0/4] Export offsets of VMCS fields as note information for kdump

[zhangyanfei]

This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
runtime state of guest machine image, such as registers, in host
machine's crash dump as VMCS format. The problem is that VMCS
internal is hidden by Intel in its specification. So, we reverse
engineering it in the way implemented in this patch set. Please note
that this processing never affects any existing kvm logic. The
VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.

Here is an example:
Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

$cat /sys/kernel/vmcsinfo
1cba8c0 2000

crash> rd -p 1cba8c0 1000
         1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
         1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
         1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
         1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
         1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
         1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
         1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
         1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
         1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
         1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
         1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
         1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
         1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
         1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
         1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
         1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
         1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
         1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
         ......

TODO:
  1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
     into vmcore.
  2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
     core file. To do this, we will modify kernel core dumper, gdb gcore
     and crash gcore.
  3. Dump guest image from the qemu-process core file into a vmcore.

zhangyanfei (4):
  x86: Add helper variables and functions to hold VMCSINFO
  KVM: VMX: Add functions to fill VMCSINFO
  ksysfs: export VMCSINFO via sysfs
  kexec: Add crash_save_vmcsinfo to update VMCSINFO

 arch/x86/include/asm/vmcsinfo.h |   42 +++++
 arch/x86/kernel/Makefile        |    2 +
 arch/x86/kernel/vmcsinfo.c      |   70 ++++++++
 arch/x86/kvm/vmx.c              |  350 +++++++++++++++++++++++++++++++++++++++
 include/linux/kexec.h           |    1 +
 kernel/kexec.c                  |   14 ++
 kernel/ksysfs.c                 |   19 ++
 7 files changed, 498 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/vmcsinfo.h
 create mode 100644 arch/x86/kernel/vmcsinfo.c

[PATCH 0/4] Export offsets of VMCS fields as note information for kdump

[zhangyanfei]

This patch set exports offsets of VMCS fields as note information for
kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
runtime state of guest machine image, such as registers, in host
machine's crash dump as VMCS format. The problem is that VMCS
internal is hidden by Intel in its specification. So, we reverse
engineering it in the way implemented in this patch set. Please note
that this processing never affects any existing kvm logic. The
VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.

Here is an example:
Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

$cat /sys/kernel/vmcsinfo
1cba8c0 2000

crash> rd -p 1cba8c0 1000
         1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
         1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
         1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
         1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
         1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
         1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
         1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
         1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
         1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
         1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
         1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
         1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
         1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
         1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
         1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
         1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
         1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
         1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
         ......

TODO:
  1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
     into vmcore.
  2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
     core file. To do this, we will modify kernel core dumper, gdb gcore
     and crash gcore.
  3. Dump guest image from the qemu-process core file into a vmcore.

zhangyanfei (4):
  x86: Add helper variables and functions to hold VMCSINFO
  KVM: VMX: Add functions to fill VMCSINFO
  ksysfs: export VMCSINFO via sysfs
  kexec: Add crash_save_vmcsinfo to update VMCSINFO

 arch/x86/include/asm/vmcsinfo.h |   42 +++++
 arch/x86/kernel/Makefile        |    2 +
 arch/x86/kernel/vmcsinfo.c      |   70 ++++++++
 arch/x86/kvm/vmx.c              |  350 +++++++++++++++++++++++++++++++++++++++
 include/linux/kexec.h           |    1 +
 kernel/kexec.c                  |   14 ++
 kernel/ksysfs.c                 |   19 ++
 7 files changed, 498 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/vmcsinfo.h
 create mode 100644 arch/x86/kernel/vmcsinfo.c

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

[PATCH 1/4] x86: Add helper variables and functions to hold VMCSINFO

[zhangyanfei]

This patch provides a set of variables to hold the VMCSINFO and also
some helper functions to help fill the VMCSINFO.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 arch/x86/include/asm/vmcsinfo.h |   42 +++++++++++++++++++++++
 arch/x86/kernel/Makefile        |    2 +
 arch/x86/kernel/vmcsinfo.c      |   70 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 114 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/vmcsinfo.h
 create mode 100644 arch/x86/kernel/vmcsinfo.c

diff --git a/arch/x86/include/asm/vmcsinfo.h b/arch/x86/include/asm/vmcsinfo.h
new file mode 100644
index 0000000..cfdc984
--- /dev/null
+++ b/arch/x86/include/asm/vmcsinfo.h
@@ -0,0 +1,42 @@
+#ifndef _ASM_X86_VMCSINFO_H
+#define _ASM_X86_VMCSINFO_H
+
+#ifndef __ASSEMBLY__
+#include <linux/types.h>
+#include <linux/elf.h>
+
+/*
+ * Currently, 2 pages are enough for vmcsinfo.
+ */
+#define VMCSINFO_BYTES             (8192)
+#define VMCSINFO_NOTE_NAME         "VMCSINFO"
+#define VMCSINFO_NOTE_NAME_BYTES   ALIGN(sizeof(VMCSINFO_NOTE_NAME), 4)
+#define VMCSINFO_NOTE_HEAD_BYTES   ALIGN(sizeof(struct elf_note), 4)
+#define VMCSINFO_NOTE_SIZE         (VMCSINFO_NOTE_HEAD_BYTES*2 \
+				    + VMCSINFO_BYTES \
+				    + VMCSINFO_NOTE_NAME_BYTES)
+
+extern size_t vmcsinfo_size;
+extern size_t vmcsinfo_max_size;
+
+extern void update_vmcsinfo_note(void);
+extern void vmcsinfo_append_str(const char *fmt, ...);
+extern unsigned long paddr_vmcsinfo_note(void);
+
+#define VMCSINFO_REVISION_ID(id) \
+	vmcsinfo_append_str("REVISION_ID=%x\n", id)
+#define VMCSINFO_FIELD16(name, value) \
+	vmcsinfo_append_str("FIELD(%s)=%04x\n", #name, value)
+#define VMCSINFO_FIELD32(name, value) \
+	vmcsinfo_append_str("FIELD(%s)=%08x\n", #name, value)
+#define VMCSINFO_FIELD64(name, value) \
+	vmcsinfo_append_str("FIELD(%s)=%016llx\n", #name, value)
+
+#ifdef CONFIG_X86_64
+#define VMCSINFO_FIELD(name, value) VMCSINFO_FIELD64(name, value)
+#else
+#define VMCSINFO_FIELD(name, value) VMCSINFO_FIELD32(name, value)
+#endif
+
+#endif /* __ASSEMBLY__ */
+#endif /* _ASM_X86_VMCSINFO_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 532d2e0..63edf33 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -102,6 +102,8 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
 obj-$(CONFIG_SWIOTLB)			+= pci-swiotlb.o
 obj-$(CONFIG_OF)			+= devicetree.o
 
+obj-y					+= vmcsinfo.o
+
 ###
 # 64 bit specific files
 ifeq ($(CONFIG_X86_64),y)
diff --git a/arch/x86/kernel/vmcsinfo.c b/arch/x86/kernel/vmcsinfo.c
new file mode 100644
index 0000000..c1306ef
--- /dev/null
+++ b/arch/x86/kernel/vmcsinfo.c
@@ -0,0 +1,70 @@
+/*
+ * Architecture specific (i386/x86_64) functions for storing vmcs
+ * field information.
+ *
+ * Created by: zhangyanfei (zhangyanfei@cn.fujitsu.com)
+ *
+ * Copyright (C) Fujitsu Corporation, 2012. All rights reserved.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include <asm/vmcsinfo.h>
+#include <linux/module.h>
+#include <linux/elf.h>
+
+static unsigned char vmcsinfo_data[VMCSINFO_BYTES];
+static u32 vmcsinfo_note[VMCSINFO_NOTE_SIZE/4];
+size_t vmcsinfo_max_size = sizeof(vmcsinfo_data);
+size_t vmcsinfo_size;
+EXPORT_SYMBOL(vmcsinfo_size);
+
+void update_vmcsinfo_note(void)
+{
+	u32 *buf = vmcsinfo_note;
+	struct elf_note note;
+
+	if (!vmcsinfo_size)
+		return;
+
+	note.n_namesz = strlen(VMCSINFO_NOTE_NAME) + 1;
+	note.n_descsz = vmcsinfo_size;
+	note.n_type   = 0;
+	memcpy(buf, &note, sizeof(note));
+	buf += (sizeof(note) + 3)/4;
+	memcpy(buf, VMCSINFO_NOTE_NAME, note.n_namesz);
+	buf += (note.n_namesz + 3)/4;
+	memcpy(buf, vmcsinfo_data, note.n_descsz);
+	buf += (note.n_descsz + 3)/4;
+
+	note.n_namesz = 0;
+	note.n_descsz = 0;
+	note.n_type   = 0;
+	memcpy(buf, &note, sizeof(note));
+}
+EXPORT_SYMBOL(update_vmcsinfo_note);
+
+void vmcsinfo_append_str(const char *fmt, ...)
+{
+	va_list args;
+	char buf[0x50];
+	int r;
+
+	va_start(args, fmt);
+	r = vsnprintf(buf, sizeof(buf), fmt, args);
+	va_end(args);
+
+	if (r + vmcsinfo_size > vmcsinfo_max_size)
+		r = vmcsinfo_max_size - vmcsinfo_size;
+
+	memcpy(&vmcsinfo_data[vmcsinfo_size], buf, r);
+
+	vmcsinfo_size += r;
+}
+EXPORT_SYMBOL(vmcsinfo_append_str);
+
+unsigned long paddr_vmcsinfo_note(void)
+{
+	return __pa((unsigned long)(char *)&vmcsinfo_note);
+}
-- 
1.7.1

[PATCH 1/4] x86: Add helper variables and functions to hold VMCSINFO

[zhangyanfei]

This patch provides a set of variables to hold the VMCSINFO and also
some helper functions to help fill the VMCSINFO.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 arch/x86/include/asm/vmcsinfo.h |   42 +++++++++++++++++++++++
 arch/x86/kernel/Makefile        |    2 +
 arch/x86/kernel/vmcsinfo.c      |   70 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 114 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/vmcsinfo.h
 create mode 100644 arch/x86/kernel/vmcsinfo.c

diff --git a/arch/x86/include/asm/vmcsinfo.h b/arch/x86/include/asm/vmcsinfo.h
new file mode 100644
index 0000000..cfdc984
--- /dev/null
+++ b/arch/x86/include/asm/vmcsinfo.h
@@ -0,0 +1,42 @@
+#ifndef _ASM_X86_VMCSINFO_H
+#define _ASM_X86_VMCSINFO_H
+
+#ifndef __ASSEMBLY__
+#include <linux/types.h>
+#include <linux/elf.h>
+
+/*
+ * Currently, 2 pages are enough for vmcsinfo.
+ */
+#define VMCSINFO_BYTES             (8192)
+#define VMCSINFO_NOTE_NAME         "VMCSINFO"
+#define VMCSINFO_NOTE_NAME_BYTES   ALIGN(sizeof(VMCSINFO_NOTE_NAME), 4)
+#define VMCSINFO_NOTE_HEAD_BYTES   ALIGN(sizeof(struct elf_note), 4)
+#define VMCSINFO_NOTE_SIZE         (VMCSINFO_NOTE_HEAD_BYTES*2 \
+				    + VMCSINFO_BYTES \
+				    + VMCSINFO_NOTE_NAME_BYTES)
+
+extern size_t vmcsinfo_size;
+extern size_t vmcsinfo_max_size;
+
+extern void update_vmcsinfo_note(void);
+extern void vmcsinfo_append_str(const char *fmt, ...);
+extern unsigned long paddr_vmcsinfo_note(void);
+
+#define VMCSINFO_REVISION_ID(id) \
+	vmcsinfo_append_str("REVISION_ID=%x\n", id)
+#define VMCSINFO_FIELD16(name, value) \
+	vmcsinfo_append_str("FIELD(%s)=%04x\n", #name, value)
+#define VMCSINFO_FIELD32(name, value) \
+	vmcsinfo_append_str("FIELD(%s)=%08x\n", #name, value)
+#define VMCSINFO_FIELD64(name, value) \
+	vmcsinfo_append_str("FIELD(%s)=%016llx\n", #name, value)
+
+#ifdef CONFIG_X86_64
+#define VMCSINFO_FIELD(name, value) VMCSINFO_FIELD64(name, value)
+#else
+#define VMCSINFO_FIELD(name, value) VMCSINFO_FIELD32(name, value)
+#endif
+
+#endif /* __ASSEMBLY__ */
+#endif /* _ASM_X86_VMCSINFO_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 532d2e0..63edf33 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -102,6 +102,8 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
 obj-$(CONFIG_SWIOTLB)			+= pci-swiotlb.o
 obj-$(CONFIG_OF)			+= devicetree.o
 
+obj-y					+= vmcsinfo.o
+
 ###
 # 64 bit specific files
 ifeq ($(CONFIG_X86_64),y)
diff --git a/arch/x86/kernel/vmcsinfo.c b/arch/x86/kernel/vmcsinfo.c
new file mode 100644
index 0000000..c1306ef
--- /dev/null
+++ b/arch/x86/kernel/vmcsinfo.c
@@ -0,0 +1,70 @@
+/*
+ * Architecture specific (i386/x86_64) functions for storing vmcs
+ * field information.
+ *
+ * Created by: zhangyanfei (zhangyanfei@cn.fujitsu.com)
+ *
+ * Copyright (C) Fujitsu Corporation, 2012. All rights reserved.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include <asm/vmcsinfo.h>
+#include <linux/module.h>
+#include <linux/elf.h>
+
+static unsigned char vmcsinfo_data[VMCSINFO_BYTES];
+static u32 vmcsinfo_note[VMCSINFO_NOTE_SIZE/4];
+size_t vmcsinfo_max_size = sizeof(vmcsinfo_data);
+size_t vmcsinfo_size;
+EXPORT_SYMBOL(vmcsinfo_size);
+
+void update_vmcsinfo_note(void)
+{
+	u32 *buf = vmcsinfo_note;
+	struct elf_note note;
+
+	if (!vmcsinfo_size)
+		return;
+
+	note.n_namesz = strlen(VMCSINFO_NOTE_NAME) + 1;
+	note.n_descsz = vmcsinfo_size;
+	note.n_type   = 0;
+	memcpy(buf, &note, sizeof(note));
+	buf += (sizeof(note) + 3)/4;
+	memcpy(buf, VMCSINFO_NOTE_NAME, note.n_namesz);
+	buf += (note.n_namesz + 3)/4;
+	memcpy(buf, vmcsinfo_data, note.n_descsz);
+	buf += (note.n_descsz + 3)/4;
+
+	note.n_namesz = 0;
+	note.n_descsz = 0;
+	note.n_type   = 0;
+	memcpy(buf, &note, sizeof(note));
+}
+EXPORT_SYMBOL(update_vmcsinfo_note);
+
+void vmcsinfo_append_str(const char *fmt, ...)
+{
+	va_list args;
+	char buf[0x50];
+	int r;
+
+	va_start(args, fmt);
+	r = vsnprintf(buf, sizeof(buf), fmt, args);
+	va_end(args);
+
+	if (r + vmcsinfo_size > vmcsinfo_max_size)
+		r = vmcsinfo_max_size - vmcsinfo_size;
+
+	memcpy(&vmcsinfo_data[vmcsinfo_size], buf, r);
+
+	vmcsinfo_size += r;
+}
+EXPORT_SYMBOL(vmcsinfo_append_str);
+
+unsigned long paddr_vmcsinfo_note(void)
+{
+	return __pa((unsigned long)(char *)&vmcsinfo_note);
+}
-- 
1.7.1

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

[PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[zhangyanfei]

This patch is to implement the feature that at initialization of
kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
and encoded offsets of VMCS fields. The reason why we put the
VMCSINFO processing at the initialization of kvm_intel module
is that it's dangerous to rob VMX resources while kvm module is
loaded.

Note, offsets of fields below will not be filled into VMCSINFO:
1. fields defined in Intel specification (Intel® 64 and
   IA-32 Architectures Software Developer’s Manual, Volume
   3C) but not defined in *vmcs_field*.
2. fields don't exist because their corresponding control bits
   are not set.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 arch/x86/kvm/vmx.c |  350 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 350 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ad85adf..e98fafa 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -41,6 +41,7 @@
 #include <asm/i387.h>
 #include <asm/xcr.h>
 #include <asm/perf_event.h>
+#include <asm/vmcsinfo.h>
 
 #include "trace.h"
 
@@ -2599,6 +2600,353 @@ static __init int alloc_kvm_area(void)
 	return 0;
 }
 
+/*
+ * For caculating offsets of fields in VMCS data, we index every 16-bit
+ * field by this kind of format:
+ *         | --------- 16 bits ---------- |
+ *         +-------------+-+------------+-+
+ *         | high 7 bits |1| low 7 bits |0|
+ *         +-------------+-+------------+-+
+ * In high byte, the lowest bit must be 1; In low byte, the lowest bit
+ * must be 0. The two bits are set like this in case indexes in VMCS
+ * data are read as big endian mode.
+ * The remaining 14 bits of the index indicate the real offset of the
+ * field. Because the size of a VMCS region is at most 4 KBytes, so
+ * 14 bits are enough to index the whole VMCS region.
+ *
+ * ENCODING_OFFSET: encode the offset into the index of this kind.
+ */
+#define OFFSET_HIGH_SHIFT (7)
+#define OFFSET_LOW_MASK   ((1 << OFFSET_HIGH_SHIFT) - 1) /* 0x7f */
+#define OFFSET_HIGH_MASK  (OFFSET_LOW_MASK << OFFSET_HIGH_SHIFT) /* 0x3f80 */
+#define ENCODING_OFFSET(offset) \
+	((((offset) & OFFSET_LOW_MASK) << 1) + \
+	((((offset) & OFFSET_HIGH_MASK) << 2) | 0x100))
+
+/*
+ * We separate these five control fields from other fields
+ * because some fields only exist on processors that support
+ * the 1-setting of control bits in the five control fields.
+ */
+static inline void append_control_field(void)
+{
+#define CONTROL_FIELD_OFFSET(field) \
+	VMCSINFO_FIELD32(field, vmcs_read32(field))
+
+	CONTROL_FIELD_OFFSET(PIN_BASED_VM_EXEC_CONTROL);
+	CONTROL_FIELD_OFFSET(CPU_BASED_VM_EXEC_CONTROL);
+	if (cpu_has_secondary_exec_ctrls()) {
+		CONTROL_FIELD_OFFSET(SECONDARY_VM_EXEC_CONTROL);
+	}
+	CONTROL_FIELD_OFFSET(VM_EXIT_CONTROLS);
+	CONTROL_FIELD_OFFSET(VM_ENTRY_CONTROLS);
+}
+
+static inline void append_field16(void)
+{
+#define FIELD_OFFSET16(field) \
+	VMCSINFO_FIELD16(field, vmcs_read16(field));
+
+	FIELD_OFFSET16(GUEST_ES_SELECTOR);
+	FIELD_OFFSET16(GUEST_CS_SELECTOR);
+	FIELD_OFFSET16(GUEST_SS_SELECTOR);
+	FIELD_OFFSET16(GUEST_DS_SELECTOR);
+	FIELD_OFFSET16(GUEST_FS_SELECTOR);
+	FIELD_OFFSET16(GUEST_GS_SELECTOR);
+	FIELD_OFFSET16(GUEST_LDTR_SELECTOR);
+	FIELD_OFFSET16(GUEST_TR_SELECTOR);
+	FIELD_OFFSET16(HOST_ES_SELECTOR);
+	FIELD_OFFSET16(HOST_CS_SELECTOR);
+	FIELD_OFFSET16(HOST_SS_SELECTOR);
+	FIELD_OFFSET16(HOST_DS_SELECTOR);
+	FIELD_OFFSET16(HOST_FS_SELECTOR);
+	FIELD_OFFSET16(HOST_GS_SELECTOR);
+	FIELD_OFFSET16(HOST_TR_SELECTOR);
+}
+
+static inline void append_field64(void)
+{
+#define FIELD_OFFSET64(field) \
+	VMCSINFO_FIELD64(field, vmcs_read64(field));
+
+	FIELD_OFFSET64(IO_BITMAP_A);
+	FIELD_OFFSET64(IO_BITMAP_A_HIGH);
+	FIELD_OFFSET64(IO_BITMAP_B);
+	FIELD_OFFSET64(IO_BITMAP_B_HIGH);
+	FIELD_OFFSET64(VM_EXIT_MSR_STORE_ADDR);
+	FIELD_OFFSET64(VM_EXIT_MSR_STORE_ADDR_HIGH);
+	FIELD_OFFSET64(VM_EXIT_MSR_LOAD_ADDR);
+	FIELD_OFFSET64(VM_EXIT_MSR_LOAD_ADDR_HIGH);
+	FIELD_OFFSET64(VM_ENTRY_MSR_LOAD_ADDR);
+	FIELD_OFFSET64(VM_ENTRY_MSR_LOAD_ADDR_HIGH);
+	FIELD_OFFSET64(TSC_OFFSET);
+	FIELD_OFFSET64(TSC_OFFSET_HIGH);
+	FIELD_OFFSET64(VMCS_LINK_POINTER);
+	FIELD_OFFSET64(VMCS_LINK_POINTER_HIGH);
+	FIELD_OFFSET64(GUEST_IA32_DEBUGCTL);
+	FIELD_OFFSET64(GUEST_IA32_DEBUGCTL_HIGH);
+
+	if (cpu_has_vmx_msr_bitmap()) {
+		FIELD_OFFSET64(MSR_BITMAP);
+		FIELD_OFFSET64(MSR_BITMAP_HIGH);
+	}
+
+	if (cpu_has_vmx_tpr_shadow()) {
+		FIELD_OFFSET64(VIRTUAL_APIC_PAGE_ADDR);
+		FIELD_OFFSET64(VIRTUAL_APIC_PAGE_ADDR_HIGH);
+	}
+
+	if (cpu_has_secondary_exec_ctrls()) {
+		if (vmcs_config.cpu_based_2nd_exec_ctrl &
+		    SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES) {
+			FIELD_OFFSET64(APIC_ACCESS_ADDR);
+			FIELD_OFFSET64(APIC_ACCESS_ADDR_HIGH);
+		}
+		if (cpu_has_vmx_ept()) {
+			FIELD_OFFSET64(EPT_POINTER);
+			FIELD_OFFSET64(EPT_POINTER_HIGH);
+			FIELD_OFFSET64(GUEST_PHYSICAL_ADDRESS);
+			FIELD_OFFSET64(GUEST_PHYSICAL_ADDRESS_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR0);
+			FIELD_OFFSET64(GUEST_PDPTR0_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR1);
+			FIELD_OFFSET64(GUEST_PDPTR1_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR2);
+			FIELD_OFFSET64(GUEST_PDPTR2_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR3);
+			FIELD_OFFSET64(GUEST_PDPTR3_HIGH);
+		}
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_SAVE_IA32_PAT || \
+	    vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) {
+		FIELD_OFFSET64(GUEST_IA32_PAT);
+		FIELD_OFFSET64(GUEST_IA32_PAT_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_SAVE_IA32_EFER || \
+	    vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_EFER) {
+		FIELD_OFFSET64(GUEST_IA32_EFER);
+		FIELD_OFFSET64(GUEST_IA32_EFER_HIGH);
+	}
+
+	if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL) {
+		FIELD_OFFSET64(GUEST_IA32_PERF_GLOBAL_CTRL);
+		FIELD_OFFSET64(GUEST_IA32_PERF_GLOBAL_CTRL_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PAT) {
+		FIELD_OFFSET64(HOST_IA32_PAT);
+		FIELD_OFFSET64(HOST_IA32_PAT_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_EFER) {
+		FIELD_OFFSET64(HOST_IA32_EFER);
+		FIELD_OFFSET64(HOST_IA32_EFER_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL) {
+		FIELD_OFFSET64(HOST_IA32_PERF_GLOBAL_CTRL);
+		FIELD_OFFSET64(HOST_IA32_PERF_GLOBAL_CTRL_HIGH);
+	}
+}
+
+static inline void append_field32(void)
+{
+#define FIELD_OFFSET32(field) \
+	VMCSINFO_FIELD32(field, vmcs_read32(field));
+
+	FIELD_OFFSET32(EXCEPTION_BITMAP);
+	FIELD_OFFSET32(PAGE_FAULT_ERROR_CODE_MASK);
+	FIELD_OFFSET32(PAGE_FAULT_ERROR_CODE_MATCH);
+	FIELD_OFFSET32(CR3_TARGET_COUNT);
+	FIELD_OFFSET32(VM_EXIT_MSR_STORE_COUNT);
+	FIELD_OFFSET32(VM_EXIT_MSR_LOAD_COUNT);
+	FIELD_OFFSET32(VM_ENTRY_MSR_LOAD_COUNT);
+	FIELD_OFFSET32(VM_ENTRY_INTR_INFO_FIELD);
+	FIELD_OFFSET32(VM_ENTRY_EXCEPTION_ERROR_CODE);
+	FIELD_OFFSET32(VM_ENTRY_INSTRUCTION_LEN);
+	FIELD_OFFSET32(VM_INSTRUCTION_ERROR);
+	FIELD_OFFSET32(VM_EXIT_REASON);
+	FIELD_OFFSET32(VM_EXIT_INTR_INFO);
+	FIELD_OFFSET32(VM_EXIT_INTR_ERROR_CODE);
+	FIELD_OFFSET32(IDT_VECTORING_INFO_FIELD);
+	FIELD_OFFSET32(IDT_VECTORING_ERROR_CODE);
+	FIELD_OFFSET32(VM_EXIT_INSTRUCTION_LEN);
+	FIELD_OFFSET32(VMX_INSTRUCTION_INFO);
+	FIELD_OFFSET32(GUEST_ES_LIMIT);
+	FIELD_OFFSET32(GUEST_CS_LIMIT);
+	FIELD_OFFSET32(GUEST_SS_LIMIT);
+	FIELD_OFFSET32(GUEST_DS_LIMIT);
+	FIELD_OFFSET32(GUEST_FS_LIMIT);
+	FIELD_OFFSET32(GUEST_GS_LIMIT);
+	FIELD_OFFSET32(GUEST_LDTR_LIMIT);
+	FIELD_OFFSET32(GUEST_TR_LIMIT);
+	FIELD_OFFSET32(GUEST_GDTR_LIMIT);
+	FIELD_OFFSET32(GUEST_IDTR_LIMIT);
+	FIELD_OFFSET32(GUEST_ES_AR_BYTES);
+	FIELD_OFFSET32(GUEST_CS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_SS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_DS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_FS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_GS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_LDTR_AR_BYTES);
+	FIELD_OFFSET32(GUEST_TR_AR_BYTES);
+	FIELD_OFFSET32(GUEST_INTERRUPTIBILITY_INFO);
+	FIELD_OFFSET32(GUEST_ACTIVITY_STATE);
+	FIELD_OFFSET32(GUEST_SYSENTER_CS);
+	FIELD_OFFSET32(HOST_IA32_SYSENTER_CS);
+
+	if (cpu_has_vmx_tpr_shadow()) {
+		FIELD_OFFSET32(TPR_THRESHOLD);
+	}
+	if (cpu_has_secondary_exec_ctrls()) {
+		if (cpu_has_vmx_ple()) {
+			FIELD_OFFSET32(PLE_GAP);
+			FIELD_OFFSET32(PLE_WINDOW);
+		}
+	}
+}
+
+static inline void append_field(void)
+{
+#define FIELD_OFFSET(field) \
+	VMCSINFO_FIELD(field, vmcs_readl(field));
+
+	FIELD_OFFSET(CR0_GUEST_HOST_MASK);
+	FIELD_OFFSET(CR4_GUEST_HOST_MASK);
+	FIELD_OFFSET(CR0_READ_SHADOW);
+	FIELD_OFFSET(CR4_READ_SHADOW);
+	FIELD_OFFSET(CR3_TARGET_VALUE0);
+	FIELD_OFFSET(CR3_TARGET_VALUE1);
+	FIELD_OFFSET(CR3_TARGET_VALUE2);
+	FIELD_OFFSET(CR3_TARGET_VALUE3);
+	FIELD_OFFSET(EXIT_QUALIFICATION);
+	FIELD_OFFSET(GUEST_LINEAR_ADDRESS);
+	FIELD_OFFSET(GUEST_CR0);
+	FIELD_OFFSET(GUEST_CR3);
+	FIELD_OFFSET(GUEST_CR4);
+	FIELD_OFFSET(GUEST_ES_BASE);
+	FIELD_OFFSET(GUEST_CS_BASE);
+	FIELD_OFFSET(GUEST_SS_BASE);
+	FIELD_OFFSET(GUEST_DS_BASE);
+	FIELD_OFFSET(GUEST_FS_BASE);
+	FIELD_OFFSET(GUEST_GS_BASE);
+	FIELD_OFFSET(GUEST_LDTR_BASE);
+	FIELD_OFFSET(GUEST_TR_BASE);
+	FIELD_OFFSET(GUEST_GDTR_BASE);
+	FIELD_OFFSET(GUEST_IDTR_BASE);
+	FIELD_OFFSET(GUEST_DR7);
+	FIELD_OFFSET(GUEST_RSP);
+	FIELD_OFFSET(GUEST_RIP);
+	FIELD_OFFSET(GUEST_RFLAGS);
+	FIELD_OFFSET(GUEST_PENDING_DBG_EXCEPTIONS);
+	FIELD_OFFSET(GUEST_SYSENTER_ESP);
+	FIELD_OFFSET(GUEST_SYSENTER_EIP);
+	FIELD_OFFSET(HOST_CR0);
+	FIELD_OFFSET(HOST_CR3);
+	FIELD_OFFSET(HOST_CR4);
+	FIELD_OFFSET(HOST_FS_BASE);
+	FIELD_OFFSET(HOST_GS_BASE);
+	FIELD_OFFSET(HOST_TR_BASE);
+	FIELD_OFFSET(HOST_GDTR_BASE);
+	FIELD_OFFSET(HOST_IDTR_BASE);
+	FIELD_OFFSET(HOST_IA32_SYSENTER_ESP);
+	FIELD_OFFSET(HOST_IA32_SYSENTER_EIP);
+	FIELD_OFFSET(HOST_RSP);
+	FIELD_OFFSET(HOST_RIP);
+}
+
+/*
+ * alloc_vmcsinfo will be called at the initialization of
+ * kvm_intel module to fill VMCSINFO. The VMCSINFO contains
+ * a VMCS revision identifier and encoded offsets of fields.
+ *
+ * Note, offsets of fields below will not be filled into
+ * VMCSINFO:
+ * 1. fields defined in Intel specification (Intel® 64 and
+ *    IA-32 Architectures Software Developer’s Manual, Volume
+ *    3C) but not defined in *vmcs_field*.
+ * 2. fields don't exist because their corresponding
+ *    control bits are not set.
+ */
+static __init void alloc_vmcsinfo(void)
+{
+/*
+ * The first 8 bytes in vmcs region are for
+ *   VMCS revision identifier
+ *   VMX-abort indicator
+ */
+#define FIELD_START (8)
+
+	int offset, flag;
+	struct vmcs *vmcs;
+	u64 old_msr, test_bits;
+
+	flag = 0;
+
+	if (vmcsinfo_size)
+		return;
+
+	vmcs = alloc_vmcs();
+	if (!vmcs) {
+		return;
+	}
+
+	rdmsrl(MSR_IA32_FEATURE_CONTROL, old_msr);
+
+	test_bits = FEATURE_CONTROL_LOCKED;
+	test_bits |= FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
+	if (tboot_enabled())
+		test_bits |= FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX;
+	if ((old_msr & test_bits) != test_bits)
+		wrmsrl(MSR_IA32_FEATURE_CONTROL, old_msr | test_bits);
+
+	flag = read_cr4() & X86_CR4_VMXE;
+	if (!flag)
+		write_cr4(read_cr4() | X86_CR4_VMXE);
+
+	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
+	vmcs_load(vmcs);
+
+	VMCSINFO_REVISION_ID(vmcs->revision_id);
+
+	/*
+	 * Write encoded offsets into VMCS data for later vmcs_read.
+	 */
+	for (offset = FIELD_START; offset < vmcs_config.size;
+	     offset += sizeof(u16))
+		*(u16 *)((char *)vmcs + offset) = ENCODING_OFFSET(offset);
+
+	append_control_field();
+
+	vmcs_write32(PIN_BASED_VM_EXEC_CONTROL,
+		     vmcs_config.pin_based_exec_ctrl);
+	vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
+		     vmcs_config.cpu_based_exec_ctrl);
+	if (cpu_has_secondary_exec_ctrls()) {
+		vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
+			     vmcs_config.cpu_based_2nd_exec_ctrl);
+	}
+	vmcs_write32(VM_EXIT_CONTROLS, vmcs_config.vmexit_ctrl);
+	vmcs_write32(VM_ENTRY_CONTROLS, vmcs_config.vmentry_ctrl);
+
+	append_field16();
+	append_field64();
+	append_field32();
+	append_field();
+
+	update_vmcsinfo_note();
+
+	vmcs_clear(vmcs);
+	kvm_cpu_vmxoff();
+	if (!flag)
+		write_cr4(read_cr4() & ~X86_CR4_VMXE);
+	wrmsrl(MSR_IA32_FEATURE_CONTROL, old_msr);
+
+	free_vmcs(vmcs);
+}
+
 static __init int hardware_setup(void)
 {
 	if (setup_vmcs_config(&vmcs_config) < 0)
@@ -7227,6 +7575,8 @@ static int __init vmx_init(void)
 	if (r)
 		goto out3;
 
+	alloc_vmcsinfo();
+
 	vmx_disable_intercept_for_msr(MSR_FS_BASE, false);
 	vmx_disable_intercept_for_msr(MSR_GS_BASE, false);
 	vmx_disable_intercept_for_msr(MSR_KERNEL_GS_BASE, true);
-- 
1.7.1

[PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[zhangyanfei]

This patch is to implement the feature that at initialization of
kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
and encoded offsets of VMCS fields. The reason why we put the
VMCSINFO processing at the initialization of kvm_intel module
is that it's dangerous to rob VMX resources while kvm module is
loaded.

Note, offsets of fields below will not be filled into VMCSINFO:
1. fields defined in Intel specification (Intel® 64 and
   IA-32 Architectures Software Developer’s Manual, Volume
   3C) but not defined in *vmcs_field*.
2. fields don't exist because their corresponding control bits
   are not set.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 arch/x86/kvm/vmx.c |  350 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 350 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ad85adf..e98fafa 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -41,6 +41,7 @@
 #include <asm/i387.h>
 #include <asm/xcr.h>
 #include <asm/perf_event.h>
+#include <asm/vmcsinfo.h>
 
 #include "trace.h"
 
@@ -2599,6 +2600,353 @@ static __init int alloc_kvm_area(void)
 	return 0;
 }
 
+/*
+ * For caculating offsets of fields in VMCS data, we index every 16-bit
+ * field by this kind of format:
+ *         | --------- 16 bits ---------- |
+ *         +-------------+-+------------+-+
+ *         | high 7 bits |1| low 7 bits |0|
+ *         +-------------+-+------------+-+
+ * In high byte, the lowest bit must be 1; In low byte, the lowest bit
+ * must be 0. The two bits are set like this in case indexes in VMCS
+ * data are read as big endian mode.
+ * The remaining 14 bits of the index indicate the real offset of the
+ * field. Because the size of a VMCS region is at most 4 KBytes, so
+ * 14 bits are enough to index the whole VMCS region.
+ *
+ * ENCODING_OFFSET: encode the offset into the index of this kind.
+ */
+#define OFFSET_HIGH_SHIFT (7)
+#define OFFSET_LOW_MASK   ((1 << OFFSET_HIGH_SHIFT) - 1) /* 0x7f */
+#define OFFSET_HIGH_MASK  (OFFSET_LOW_MASK << OFFSET_HIGH_SHIFT) /* 0x3f80 */
+#define ENCODING_OFFSET(offset) \
+	((((offset) & OFFSET_LOW_MASK) << 1) + \
+	((((offset) & OFFSET_HIGH_MASK) << 2) | 0x100))
+
+/*
+ * We separate these five control fields from other fields
+ * because some fields only exist on processors that support
+ * the 1-setting of control bits in the five control fields.
+ */
+static inline void append_control_field(void)
+{
+#define CONTROL_FIELD_OFFSET(field) \
+	VMCSINFO_FIELD32(field, vmcs_read32(field))
+
+	CONTROL_FIELD_OFFSET(PIN_BASED_VM_EXEC_CONTROL);
+	CONTROL_FIELD_OFFSET(CPU_BASED_VM_EXEC_CONTROL);
+	if (cpu_has_secondary_exec_ctrls()) {
+		CONTROL_FIELD_OFFSET(SECONDARY_VM_EXEC_CONTROL);
+	}
+	CONTROL_FIELD_OFFSET(VM_EXIT_CONTROLS);
+	CONTROL_FIELD_OFFSET(VM_ENTRY_CONTROLS);
+}
+
+static inline void append_field16(void)
+{
+#define FIELD_OFFSET16(field) \
+	VMCSINFO_FIELD16(field, vmcs_read16(field));
+
+	FIELD_OFFSET16(GUEST_ES_SELECTOR);
+	FIELD_OFFSET16(GUEST_CS_SELECTOR);
+	FIELD_OFFSET16(GUEST_SS_SELECTOR);
+	FIELD_OFFSET16(GUEST_DS_SELECTOR);
+	FIELD_OFFSET16(GUEST_FS_SELECTOR);
+	FIELD_OFFSET16(GUEST_GS_SELECTOR);
+	FIELD_OFFSET16(GUEST_LDTR_SELECTOR);
+	FIELD_OFFSET16(GUEST_TR_SELECTOR);
+	FIELD_OFFSET16(HOST_ES_SELECTOR);
+	FIELD_OFFSET16(HOST_CS_SELECTOR);
+	FIELD_OFFSET16(HOST_SS_SELECTOR);
+	FIELD_OFFSET16(HOST_DS_SELECTOR);
+	FIELD_OFFSET16(HOST_FS_SELECTOR);
+	FIELD_OFFSET16(HOST_GS_SELECTOR);
+	FIELD_OFFSET16(HOST_TR_SELECTOR);
+}
+
+static inline void append_field64(void)
+{
+#define FIELD_OFFSET64(field) \
+	VMCSINFO_FIELD64(field, vmcs_read64(field));
+
+	FIELD_OFFSET64(IO_BITMAP_A);
+	FIELD_OFFSET64(IO_BITMAP_A_HIGH);
+	FIELD_OFFSET64(IO_BITMAP_B);
+	FIELD_OFFSET64(IO_BITMAP_B_HIGH);
+	FIELD_OFFSET64(VM_EXIT_MSR_STORE_ADDR);
+	FIELD_OFFSET64(VM_EXIT_MSR_STORE_ADDR_HIGH);
+	FIELD_OFFSET64(VM_EXIT_MSR_LOAD_ADDR);
+	FIELD_OFFSET64(VM_EXIT_MSR_LOAD_ADDR_HIGH);
+	FIELD_OFFSET64(VM_ENTRY_MSR_LOAD_ADDR);
+	FIELD_OFFSET64(VM_ENTRY_MSR_LOAD_ADDR_HIGH);
+	FIELD_OFFSET64(TSC_OFFSET);
+	FIELD_OFFSET64(TSC_OFFSET_HIGH);
+	FIELD_OFFSET64(VMCS_LINK_POINTER);
+	FIELD_OFFSET64(VMCS_LINK_POINTER_HIGH);
+	FIELD_OFFSET64(GUEST_IA32_DEBUGCTL);
+	FIELD_OFFSET64(GUEST_IA32_DEBUGCTL_HIGH);
+
+	if (cpu_has_vmx_msr_bitmap()) {
+		FIELD_OFFSET64(MSR_BITMAP);
+		FIELD_OFFSET64(MSR_BITMAP_HIGH);
+	}
+
+	if (cpu_has_vmx_tpr_shadow()) {
+		FIELD_OFFSET64(VIRTUAL_APIC_PAGE_ADDR);
+		FIELD_OFFSET64(VIRTUAL_APIC_PAGE_ADDR_HIGH);
+	}
+
+	if (cpu_has_secondary_exec_ctrls()) {
+		if (vmcs_config.cpu_based_2nd_exec_ctrl &
+		    SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES) {
+			FIELD_OFFSET64(APIC_ACCESS_ADDR);
+			FIELD_OFFSET64(APIC_ACCESS_ADDR_HIGH);
+		}
+		if (cpu_has_vmx_ept()) {
+			FIELD_OFFSET64(EPT_POINTER);
+			FIELD_OFFSET64(EPT_POINTER_HIGH);
+			FIELD_OFFSET64(GUEST_PHYSICAL_ADDRESS);
+			FIELD_OFFSET64(GUEST_PHYSICAL_ADDRESS_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR0);
+			FIELD_OFFSET64(GUEST_PDPTR0_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR1);
+			FIELD_OFFSET64(GUEST_PDPTR1_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR2);
+			FIELD_OFFSET64(GUEST_PDPTR2_HIGH);
+			FIELD_OFFSET64(GUEST_PDPTR3);
+			FIELD_OFFSET64(GUEST_PDPTR3_HIGH);
+		}
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_SAVE_IA32_PAT || \
+	    vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) {
+		FIELD_OFFSET64(GUEST_IA32_PAT);
+		FIELD_OFFSET64(GUEST_IA32_PAT_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_SAVE_IA32_EFER || \
+	    vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_EFER) {
+		FIELD_OFFSET64(GUEST_IA32_EFER);
+		FIELD_OFFSET64(GUEST_IA32_EFER_HIGH);
+	}
+
+	if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL) {
+		FIELD_OFFSET64(GUEST_IA32_PERF_GLOBAL_CTRL);
+		FIELD_OFFSET64(GUEST_IA32_PERF_GLOBAL_CTRL_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PAT) {
+		FIELD_OFFSET64(HOST_IA32_PAT);
+		FIELD_OFFSET64(HOST_IA32_PAT_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_EFER) {
+		FIELD_OFFSET64(HOST_IA32_EFER);
+		FIELD_OFFSET64(HOST_IA32_EFER_HIGH);
+	}
+
+	if (vmcs_config.vmexit_ctrl & VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL) {
+		FIELD_OFFSET64(HOST_IA32_PERF_GLOBAL_CTRL);
+		FIELD_OFFSET64(HOST_IA32_PERF_GLOBAL_CTRL_HIGH);
+	}
+}
+
+static inline void append_field32(void)
+{
+#define FIELD_OFFSET32(field) \
+	VMCSINFO_FIELD32(field, vmcs_read32(field));
+
+	FIELD_OFFSET32(EXCEPTION_BITMAP);
+	FIELD_OFFSET32(PAGE_FAULT_ERROR_CODE_MASK);
+	FIELD_OFFSET32(PAGE_FAULT_ERROR_CODE_MATCH);
+	FIELD_OFFSET32(CR3_TARGET_COUNT);
+	FIELD_OFFSET32(VM_EXIT_MSR_STORE_COUNT);
+	FIELD_OFFSET32(VM_EXIT_MSR_LOAD_COUNT);
+	FIELD_OFFSET32(VM_ENTRY_MSR_LOAD_COUNT);
+	FIELD_OFFSET32(VM_ENTRY_INTR_INFO_FIELD);
+	FIELD_OFFSET32(VM_ENTRY_EXCEPTION_ERROR_CODE);
+	FIELD_OFFSET32(VM_ENTRY_INSTRUCTION_LEN);
+	FIELD_OFFSET32(VM_INSTRUCTION_ERROR);
+	FIELD_OFFSET32(VM_EXIT_REASON);
+	FIELD_OFFSET32(VM_EXIT_INTR_INFO);
+	FIELD_OFFSET32(VM_EXIT_INTR_ERROR_CODE);
+	FIELD_OFFSET32(IDT_VECTORING_INFO_FIELD);
+	FIELD_OFFSET32(IDT_VECTORING_ERROR_CODE);
+	FIELD_OFFSET32(VM_EXIT_INSTRUCTION_LEN);
+	FIELD_OFFSET32(VMX_INSTRUCTION_INFO);
+	FIELD_OFFSET32(GUEST_ES_LIMIT);
+	FIELD_OFFSET32(GUEST_CS_LIMIT);
+	FIELD_OFFSET32(GUEST_SS_LIMIT);
+	FIELD_OFFSET32(GUEST_DS_LIMIT);
+	FIELD_OFFSET32(GUEST_FS_LIMIT);
+	FIELD_OFFSET32(GUEST_GS_LIMIT);
+	FIELD_OFFSET32(GUEST_LDTR_LIMIT);
+	FIELD_OFFSET32(GUEST_TR_LIMIT);
+	FIELD_OFFSET32(GUEST_GDTR_LIMIT);
+	FIELD_OFFSET32(GUEST_IDTR_LIMIT);
+	FIELD_OFFSET32(GUEST_ES_AR_BYTES);
+	FIELD_OFFSET32(GUEST_CS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_SS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_DS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_FS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_GS_AR_BYTES);
+	FIELD_OFFSET32(GUEST_LDTR_AR_BYTES);
+	FIELD_OFFSET32(GUEST_TR_AR_BYTES);
+	FIELD_OFFSET32(GUEST_INTERRUPTIBILITY_INFO);
+	FIELD_OFFSET32(GUEST_ACTIVITY_STATE);
+	FIELD_OFFSET32(GUEST_SYSENTER_CS);
+	FIELD_OFFSET32(HOST_IA32_SYSENTER_CS);
+
+	if (cpu_has_vmx_tpr_shadow()) {
+		FIELD_OFFSET32(TPR_THRESHOLD);
+	}
+	if (cpu_has_secondary_exec_ctrls()) {
+		if (cpu_has_vmx_ple()) {
+			FIELD_OFFSET32(PLE_GAP);
+			FIELD_OFFSET32(PLE_WINDOW);
+		}
+	}
+}
+
+static inline void append_field(void)
+{
+#define FIELD_OFFSET(field) \
+	VMCSINFO_FIELD(field, vmcs_readl(field));
+
+	FIELD_OFFSET(CR0_GUEST_HOST_MASK);
+	FIELD_OFFSET(CR4_GUEST_HOST_MASK);
+	FIELD_OFFSET(CR0_READ_SHADOW);
+	FIELD_OFFSET(CR4_READ_SHADOW);
+	FIELD_OFFSET(CR3_TARGET_VALUE0);
+	FIELD_OFFSET(CR3_TARGET_VALUE1);
+	FIELD_OFFSET(CR3_TARGET_VALUE2);
+	FIELD_OFFSET(CR3_TARGET_VALUE3);
+	FIELD_OFFSET(EXIT_QUALIFICATION);
+	FIELD_OFFSET(GUEST_LINEAR_ADDRESS);
+	FIELD_OFFSET(GUEST_CR0);
+	FIELD_OFFSET(GUEST_CR3);
+	FIELD_OFFSET(GUEST_CR4);
+	FIELD_OFFSET(GUEST_ES_BASE);
+	FIELD_OFFSET(GUEST_CS_BASE);
+	FIELD_OFFSET(GUEST_SS_BASE);
+	FIELD_OFFSET(GUEST_DS_BASE);
+	FIELD_OFFSET(GUEST_FS_BASE);
+	FIELD_OFFSET(GUEST_GS_BASE);
+	FIELD_OFFSET(GUEST_LDTR_BASE);
+	FIELD_OFFSET(GUEST_TR_BASE);
+	FIELD_OFFSET(GUEST_GDTR_BASE);
+	FIELD_OFFSET(GUEST_IDTR_BASE);
+	FIELD_OFFSET(GUEST_DR7);
+	FIELD_OFFSET(GUEST_RSP);
+	FIELD_OFFSET(GUEST_RIP);
+	FIELD_OFFSET(GUEST_RFLAGS);
+	FIELD_OFFSET(GUEST_PENDING_DBG_EXCEPTIONS);
+	FIELD_OFFSET(GUEST_SYSENTER_ESP);
+	FIELD_OFFSET(GUEST_SYSENTER_EIP);
+	FIELD_OFFSET(HOST_CR0);
+	FIELD_OFFSET(HOST_CR3);
+	FIELD_OFFSET(HOST_CR4);
+	FIELD_OFFSET(HOST_FS_BASE);
+	FIELD_OFFSET(HOST_GS_BASE);
+	FIELD_OFFSET(HOST_TR_BASE);
+	FIELD_OFFSET(HOST_GDTR_BASE);
+	FIELD_OFFSET(HOST_IDTR_BASE);
+	FIELD_OFFSET(HOST_IA32_SYSENTER_ESP);
+	FIELD_OFFSET(HOST_IA32_SYSENTER_EIP);
+	FIELD_OFFSET(HOST_RSP);
+	FIELD_OFFSET(HOST_RIP);
+}
+
+/*
+ * alloc_vmcsinfo will be called at the initialization of
+ * kvm_intel module to fill VMCSINFO. The VMCSINFO contains
+ * a VMCS revision identifier and encoded offsets of fields.
+ *
+ * Note, offsets of fields below will not be filled into
+ * VMCSINFO:
+ * 1. fields defined in Intel specification (Intel® 64 and
+ *    IA-32 Architectures Software Developer’s Manual, Volume
+ *    3C) but not defined in *vmcs_field*.
+ * 2. fields don't exist because their corresponding
+ *    control bits are not set.
+ */
+static __init void alloc_vmcsinfo(void)
+{
+/*
+ * The first 8 bytes in vmcs region are for
+ *   VMCS revision identifier
+ *   VMX-abort indicator
+ */
+#define FIELD_START (8)
+
+	int offset, flag;
+	struct vmcs *vmcs;
+	u64 old_msr, test_bits;
+
+	flag = 0;
+
+	if (vmcsinfo_size)
+		return;
+
+	vmcs = alloc_vmcs();
+	if (!vmcs) {
+		return;
+	}
+
+	rdmsrl(MSR_IA32_FEATURE_CONTROL, old_msr);
+
+	test_bits = FEATURE_CONTROL_LOCKED;
+	test_bits |= FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
+	if (tboot_enabled())
+		test_bits |= FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX;
+	if ((old_msr & test_bits) != test_bits)
+		wrmsrl(MSR_IA32_FEATURE_CONTROL, old_msr | test_bits);
+
+	flag = read_cr4() & X86_CR4_VMXE;
+	if (!flag)
+		write_cr4(read_cr4() | X86_CR4_VMXE);
+
+	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
+	vmcs_load(vmcs);
+
+	VMCSINFO_REVISION_ID(vmcs->revision_id);
+
+	/*
+	 * Write encoded offsets into VMCS data for later vmcs_read.
+	 */
+	for (offset = FIELD_START; offset < vmcs_config.size;
+	     offset += sizeof(u16))
+		*(u16 *)((char *)vmcs + offset) = ENCODING_OFFSET(offset);
+
+	append_control_field();
+
+	vmcs_write32(PIN_BASED_VM_EXEC_CONTROL,
+		     vmcs_config.pin_based_exec_ctrl);
+	vmcs_write32(CPU_BASED_VM_EXEC_CONTROL,
+		     vmcs_config.cpu_based_exec_ctrl);
+	if (cpu_has_secondary_exec_ctrls()) {
+		vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
+			     vmcs_config.cpu_based_2nd_exec_ctrl);
+	}
+	vmcs_write32(VM_EXIT_CONTROLS, vmcs_config.vmexit_ctrl);
+	vmcs_write32(VM_ENTRY_CONTROLS, vmcs_config.vmentry_ctrl);
+
+	append_field16();
+	append_field64();
+	append_field32();
+	append_field();
+
+	update_vmcsinfo_note();
+
+	vmcs_clear(vmcs);
+	kvm_cpu_vmxoff();
+	if (!flag)
+		write_cr4(read_cr4() & ~X86_CR4_VMXE);
+	wrmsrl(MSR_IA32_FEATURE_CONTROL, old_msr);
+
+	free_vmcs(vmcs);
+}
+
 static __init int hardware_setup(void)
 {
 	if (setup_vmcs_config(&vmcs_config) < 0)
@@ -7227,6 +7575,8 @@ static int __init vmx_init(void)
 	if (r)
 		goto out3;
 
+	alloc_vmcsinfo();
+
 	vmx_disable_intercept_for_msr(MSR_FS_BASE, false);
 	vmx_disable_intercept_for_msr(MSR_GS_BASE, false);
 	vmx_disable_intercept_for_msr(MSR_KERNEL_GS_BASE, true);
-- 
1.7.1

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

[PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[zhangyanfei]

This patch creates sysfs file to export where VMCSINFO is allocated,
as below:
        $ cat /sys/kernel/vmcsinfo
        1cb88a0 2000
number on the left-hand side is the physical address of VMCSINFO,
while the one on the right-hand side is the max size of VMCSINFO.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 kernel/ksysfs.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 4e316e1..becbb68 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -18,6 +18,8 @@
 #include <linux/stat.h>
 #include <linux/sched.h>
 #include <linux/capability.h>
+#include <asm/vmcsinfo.h>
+#include <asm/virtext.h>
 
 #define KERNEL_ATTR_RO(_name) \
 static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
@@ -133,6 +135,20 @@ KERNEL_ATTR_RO(vmcoreinfo);
 
 #endif /* CONFIG_KEXEC */
 
+#ifdef CONFIG_X86
+static ssize_t vmcsinfo_show(struct kobject *kobj,
+			     struct kobj_attribute *attr, char *buf)
+{
+	if (cpu_has_vmx())
+		return sprintf(buf, "%lx %x\n",
+			       paddr_vmcsinfo_note(),
+			       (unsigned int)vmcsinfo_max_size);
+	return 0;
+}
+KERNEL_ATTR_RO(vmcsinfo);
+
+#endif /* CONFIG_X86 */
+
 /* whether file capabilities are enabled */
 static ssize_t fscaps_show(struct kobject *kobj,
 				  struct kobj_attribute *attr, char *buf)
@@ -182,6 +198,9 @@ static struct attribute * kernel_attrs[] = {
 	&kexec_crash_size_attr.attr,
 	&vmcoreinfo_attr.attr,
 #endif
+#ifdef CONFIG_X86
+	&vmcsinfo_attr.attr,
+#endif
 	NULL
 };
 
-- 
1.7.1

[PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[zhangyanfei]

This patch creates sysfs file to export where VMCSINFO is allocated,
as below:
        $ cat /sys/kernel/vmcsinfo
        1cb88a0 2000
number on the left-hand side is the physical address of VMCSINFO,
while the one on the right-hand side is the max size of VMCSINFO.

Signed-off-by: zhangyanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
 kernel/ksysfs.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 4e316e1..becbb68 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -18,6 +18,8 @@
 #include <linux/stat.h>
 #include <linux/sched.h>
 #include <linux/capability.h>
+#include <asm/vmcsinfo.h>
+#include <asm/virtext.h>
 
 #define KERNEL_ATTR_RO(_name) \
 static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
@@ -133,6 +135,20 @@ KERNEL_ATTR_RO(vmcoreinfo);
 
 #endif /* CONFIG_KEXEC */
 
+#ifdef CONFIG_X86
+static ssize_t vmcsinfo_show(struct kobject *kobj,
+			     struct kobj_attribute *attr, char *buf)
+{
+	if (cpu_has_vmx())
+		return sprintf(buf, "%lx %x\n",
+			       paddr_vmcsinfo_note(),
+			       (unsigned int)vmcsinfo_max_size);
+	return 0;
+}
+KERNEL_ATTR_RO(vmcsinfo);
+
+#endif /* CONFIG_X86 */
+
 /* whether file capabilities are enabled */
 static ssize_t fscaps_show(struct kobject *kobj,
 				  struct kobj_attribute *attr, char *buf)
@@ -182,6 +198,9 @@ static struct attribute * kernel_attrs[] = {
 	&kexec_crash_size_attr.attr,
 	&vmcoreinfo_attr.attr,
 #endif
+#ifdef CONFIG_X86
+	&vmcsinfo_attr.attr,
+#endif
 	NULL
 };
 
-- 
1.7.1

[PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[zhangyanfei]

This patch creates sysfs file to export where VMCSINFO is allocated,
as below:
        $ cat /sys/kernel/vmcsinfo
        1cb88a0 2000
number on the left-hand side is the physical address of VMCSINFO,
while the one on the right-hand side is the max size of VMCSINFO.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 kernel/ksysfs.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 4e316e1..becbb68 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -18,6 +18,8 @@
 #include <linux/stat.h>
 #include <linux/sched.h>
 #include <linux/capability.h>
+#include <asm/vmcsinfo.h>
+#include <asm/virtext.h>
 
 #define KERNEL_ATTR_RO(_name) \
 static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
@@ -133,6 +135,20 @@ KERNEL_ATTR_RO(vmcoreinfo);
 
 #endif /* CONFIG_KEXEC */
 
+#ifdef CONFIG_X86
+static ssize_t vmcsinfo_show(struct kobject *kobj,
+			     struct kobj_attribute *attr, char *buf)
+{
+	if (cpu_has_vmx())
+		return sprintf(buf, "%lx %x\n",
+			       paddr_vmcsinfo_note(),
+			       (unsigned int)vmcsinfo_max_size);
+	return 0;
+}
+KERNEL_ATTR_RO(vmcsinfo);
+
+#endif /* CONFIG_X86 */
+
 /* whether file capabilities are enabled */
 static ssize_t fscaps_show(struct kobject *kobj,
 				  struct kobj_attribute *attr, char *buf)
@@ -182,6 +198,9 @@ static struct attribute * kernel_attrs[] = {
 	&kexec_crash_size_attr.attr,
 	&vmcoreinfo_attr.attr,
 #endif
+#ifdef CONFIG_X86
+	&vmcsinfo_attr.attr,
+#endif
 	NULL
 };
 
-- 
1.7.1

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

[PATCH 4/4] kexec: Add crash_save_vmcsinfo to update VMCSINFO

[zhangyanfei]

crash_save_vmcsinfo updates the VMCSINFO when kernel crashes.
If no VMCSINFO has been saved before, this function will do nothing.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 include/linux/kexec.h |    1 +
 kernel/kexec.c        |   14 ++++++++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 0d7d6a1..6e8ff13 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -145,6 +145,7 @@ void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
 unsigned long paddr_vmcoreinfo_note(void);
+void crash_save_vmcsinfo(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4e2e472..19843ef 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -38,6 +38,7 @@
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/sections.h>
+#include <asm/vmcsinfo.h>
 
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t __percpu *crash_notes;
@@ -1094,6 +1095,7 @@ void crash_kexec(struct pt_regs *regs)
 
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
+			crash_save_vmcsinfo();
 			machine_crash_shutdown(&fixed_regs);
 			machine_kexec(kexec_crash_image);
 		}
@@ -1458,6 +1460,18 @@ unsigned long __attribute__ ((weak)) paddr_vmcoreinfo_note(void)
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
 
+#ifdef CONFIG_X86
+void crash_save_vmcsinfo(void)
+{
+	if (!vmcsinfo_size)
+		return;
+	vmcsinfo_append_str("CRASHTIME=%ld", get_seconds());
+	update_vmcsinfo_note();
+}
+#else
+void crash_save_vmcsinfo(void) {}
+#endif /* CONFIG_X86 */
+
 static int __init crash_save_vmcoreinfo_init(void)
 {
 	VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
-- 
1.7.1

[PATCH 4/4] kexec: Add crash_save_vmcsinfo to update VMCSINFO

[zhangyanfei]

crash_save_vmcsinfo updates the VMCSINFO when kernel crashes.
If no VMCSINFO has been saved before, this function will do nothing.

Signed-off-by: zhangyanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
 include/linux/kexec.h |    1 +
 kernel/kexec.c        |   14 ++++++++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 0d7d6a1..6e8ff13 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -145,6 +145,7 @@ void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
 unsigned long paddr_vmcoreinfo_note(void);
+void crash_save_vmcsinfo(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4e2e472..19843ef 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -38,6 +38,7 @@
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/sections.h>
+#include <asm/vmcsinfo.h>
 
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t __percpu *crash_notes;
@@ -1094,6 +1095,7 @@ void crash_kexec(struct pt_regs *regs)
 
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
+			crash_save_vmcsinfo();
 			machine_crash_shutdown(&fixed_regs);
 			machine_kexec(kexec_crash_image);
 		}
@@ -1458,6 +1460,18 @@ unsigned long __attribute__ ((weak)) paddr_vmcoreinfo_note(void)
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
 
+#ifdef CONFIG_X86
+void crash_save_vmcsinfo(void)
+{
+	if (!vmcsinfo_size)
+		return;
+	vmcsinfo_append_str("CRASHTIME=%ld", get_seconds());
+	update_vmcsinfo_note();
+}
+#else
+void crash_save_vmcsinfo(void) {}
+#endif /* CONFIG_X86 */
+
 static int __init crash_save_vmcoreinfo_init(void)
 {
 	VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
-- 
1.7.1

[PATCH 4/4] kexec: Add crash_save_vmcsinfo to update VMCSINFO

[zhangyanfei]

crash_save_vmcsinfo updates the VMCSINFO when kernel crashes.
If no VMCSINFO has been saved before, this function will do nothing.

Signed-off-by: zhangyanfei <zhangyanfei@cn.fujitsu.com>
---
 include/linux/kexec.h |    1 +
 kernel/kexec.c        |   14 ++++++++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 0d7d6a1..6e8ff13 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -145,6 +145,7 @@ void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
 unsigned long paddr_vmcoreinfo_note(void);
+void crash_save_vmcsinfo(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4e2e472..19843ef 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -38,6 +38,7 @@
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/sections.h>
+#include <asm/vmcsinfo.h>
 
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t __percpu *crash_notes;
@@ -1094,6 +1095,7 @@ void crash_kexec(struct pt_regs *regs)
 
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
+			crash_save_vmcsinfo();
 			machine_crash_shutdown(&fixed_regs);
 			machine_kexec(kexec_crash_image);
 		}
@@ -1458,6 +1460,18 @@ unsigned long __attribute__ ((weak)) paddr_vmcoreinfo_note(void)
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
 
+#ifdef CONFIG_X86
+void crash_save_vmcsinfo(void)
+{
+	if (!vmcsinfo_size)
+		return;
+	vmcsinfo_append_str("CRASHTIME=%ld", get_seconds());
+	update_vmcsinfo_note();
+}
+#else
+void crash_save_vmcsinfo(void) {}
+#endif /* CONFIG_X86 */
+
 static int __init crash_save_vmcoreinfo_init(void)
 {
 	VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
-- 
1.7.1

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

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[Avi Kivity]

On 04/11/2012 04:50 AM, zhangyanfei wrote:
> This patch is to implement the feature that at initialization of
> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
> and encoded offsets of VMCS fields. The reason why we put the
> VMCSINFO processing at the initialization of kvm_intel module
> is that it's dangerous to rob VMX resources while kvm module is
> loaded.

Maybe it should be done by a separate module.

> +
> +	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
> +	vmcs_load(vmcs);

Should do this after writing into the vmcs directly (vmcs_load() may
cache some information for vmcs_read()).

> +
> +	VMCSINFO_REVISION_ID(vmcs->revision_id);
> +
> +	/*
> +	 * Write encoded offsets into VMCS data for later vmcs_read.
> +	 */
> +	for (offset = FIELD_START; offset < vmcs_config.size;
> +	     offset += sizeof(u16))
> +		*(u16 *)((char *)vmcs + offset) = ENCODING_OFFSET(offset);

This assumes vmcs field contents use the same encoding as
vmread/vmwrite.  I guess it's a reasonable assumption.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[Avi Kivity]

On 04/11/2012 04:50 AM, zhangyanfei wrote:
> This patch is to implement the feature that at initialization of
> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
> and encoded offsets of VMCS fields. The reason why we put the
> VMCSINFO processing at the initialization of kvm_intel module
> is that it's dangerous to rob VMX resources while kvm module is
> loaded.

Maybe it should be done by a separate module.

> +
> +	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
> +	vmcs_load(vmcs);

Should do this after writing into the vmcs directly (vmcs_load() may
cache some information for vmcs_read()).

> +
> +	VMCSINFO_REVISION_ID(vmcs->revision_id);
> +
> +	/*
> +	 * Write encoded offsets into VMCS data for later vmcs_read.
> +	 */
> +	for (offset = FIELD_START; offset < vmcs_config.size;
> +	     offset += sizeof(u16))
> +		*(u16 *)((char *)vmcs + offset) = ENCODING_OFFSET(offset);

This assumes vmcs field contents use the same encoding as
vmread/vmwrite.  I guess it's a reasonable assumption.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[Avi Kivity]

On 04/11/2012 04:50 AM, zhangyanfei wrote:
> This patch is to implement the feature that at initialization of
> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
> and encoded offsets of VMCS fields. The reason why we put the
> VMCSINFO processing at the initialization of kvm_intel module
> is that it's dangerous to rob VMX resources while kvm module is
> loaded.

Maybe it should be done by a separate module.

> +
> +	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
> +	vmcs_load(vmcs);

Should do this after writing into the vmcs directly (vmcs_load() may
cache some information for vmcs_read()).

> +
> +	VMCSINFO_REVISION_ID(vmcs->revision_id);
> +
> +	/*
> +	 * Write encoded offsets into VMCS data for later vmcs_read.
> +	 */
> +	for (offset = FIELD_START; offset < vmcs_config.size;
> +	     offset += sizeof(u16))
> +		*(u16 *)((char *)vmcs + offset) = ENCODING_OFFSET(offset);

This assumes vmcs field contents use the same encoding as
vmread/vmwrite.  I guess it's a reasonable assumption.


-- 
error compiling committee.c: too many arguments to function


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

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

[Avi Kivity]

On 04/11/2012 04:39 AM, zhangyanfei wrote:
> This patch set exports offsets of VMCS fields as note information for
> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> runtime state of guest machine image, such as registers, in host
> machine's crash dump as VMCS format. The problem is that VMCS
> internal is hidden by Intel in its specification. So, we reverse
> engineering it in the way implemented in this patch set. Please note
> that this processing never affects any existing kvm logic. The
> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>
> Here is an example:
> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>
> $cat /sys/kernel/vmcsinfo
> 1cba8c0 2000
>
> crash> rd -p 1cba8c0 1000
>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>          ......

Would be nicer to have a simple binary encoding <field> <offset> instead
of this.

> TODO:
>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>      into vmcore.
>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>      core file. To do this, we will modify kernel core dumper, gdb gcore
>      and crash gcore.


Seems excessive.  Why do you want vmcs information in qemu cores?  A
qemu crash is very rarely related to kvm, let alone the vmcs.  I
understand that you may want it in a kernel core dump, though I've never
needed to myself.  Can you outline a case where this data was needed?

>   3. Dump guest image from the qemu-process core file into a vmcore.

For this perhaps a different approach is better - modify the core dumper
to call kvm to extract the relevant vmcs information into an elf note. 
This way there is no need to reconstruct the guest data from the
offsets.  It's also more reliable, since vmread can access cached fields
that direct memory access cannot.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/11/2012 04:39 AM, zhangyanfei wrote:
> This patch set exports offsets of VMCS fields as note information for
> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> runtime state of guest machine image, such as registers, in host
> machine's crash dump as VMCS format. The problem is that VMCS
> internal is hidden by Intel in its specification. So, we reverse
> engineering it in the way implemented in this patch set. Please note
> that this processing never affects any existing kvm logic. The
> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>
> Here is an example:
> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>
> $cat /sys/kernel/vmcsinfo
> 1cba8c0 2000
>
> crash> rd -p 1cba8c0 1000
>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>          ......

Would be nicer to have a simple binary encoding <field> <offset> instead
of this.

> TODO:
>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>      into vmcore.
>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>      core file. To do this, we will modify kernel core dumper, gdb gcore
>      and crash gcore.


Seems excessive.  Why do you want vmcs information in qemu cores?  A
qemu crash is very rarely related to kvm, let alone the vmcs.  I
understand that you may want it in a kernel core dump, though I've never
needed to myself.  Can you outline a case where this data was needed?

>   3. Dump guest image from the qemu-process core file into a vmcore.

For this perhaps a different approach is better - modify the core dumper
to call kvm to extract the relevant vmcs information into an elf note. 
This way there is no need to reconstruct the guest data from the
offsets.  It's also more reliable, since vmread can access cached fields
that direct memory access cannot.

-- 
error compiling committee.c: too many arguments to function


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

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

[zhangyanfei]

于 2012年04月11日 16:56, Avi Kivity 写道:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash> rd -p 1cba8c0 1000
>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>          ......
> 
> Would be nicer to have a simple binary encoding <field> <offset> instead
> of this.

Agreed.

> 
>> TODO:
>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>      into vmcore.
>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>      and crash gcore.
> 
> 
> Seems excessive.  Why do you want vmcs information in qemu cores?  A
> qemu crash is very rarely related to kvm, let alone the vmcs.  I
> understand that you may want it in a kernel core dump, though I've never
> needed to myself.  Can you outline a case where this data was needed?
> 

If a qemu process comes to a fatal error that causes itself to be core dumped
by kernel, the running guest based on the qemu process will be included in that
qemu core file. But with no vmcsinfo information in qemu core file, we could not
get the guest's states(registers' values), then we could not make a complete
guest vmcore.

>>   3. Dump guest image from the qemu-process core file into a vmcore.
> 
> For this perhaps a different approach is better - modify the core dumper
> to call kvm to extract the relevant vmcs information into an elf note. 
> This way there is no need to reconstruct the guest data from the
> offsets.  It's also more reliable, since vmread can access cached fields
> that direct memory access cannot.
> 

Does this approach is a replacement for TODO 2 ? That is to say, when generating
a qemu core by kernel core dumper, we could call kvm to extract the relevant vmcs
information into an elf note instead of VMCSINFO and the whole vmcs regions.

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

[zhangyanfei]

于 2012年04月11日 16:56, Avi Kivity 写道:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash> rd -p 1cba8c0 1000
>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>          ......
> 
> Would be nicer to have a simple binary encoding <field> <offset> instead
> of this.

Agreed.

> 
>> TODO:
>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>      into vmcore.
>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>      and crash gcore.
> 
> 
> Seems excessive.  Why do you want vmcs information in qemu cores?  A
> qemu crash is very rarely related to kvm, let alone the vmcs.  I
> understand that you may want it in a kernel core dump, though I've never
> needed to myself.  Can you outline a case where this data was needed?
> 

If a qemu process comes to a fatal error that causes itself to be core dumped
by kernel, the running guest based on the qemu process will be included in that
qemu core file. But with no vmcsinfo information in qemu core file, we could not
get the guest's states(registers' values), then we could not make a complete
guest vmcore.

>>   3. Dump guest image from the qemu-process core file into a vmcore.
> 
> For this perhaps a different approach is better - modify the core dumper
> to call kvm to extract the relevant vmcs information into an elf note. 
> This way there is no need to reconstruct the guest data from the
> offsets.  It's also more reliable, since vmread can access cached fields
> that direct memory access cannot.
> 

Does this approach is a replacement for TODO 2 ? That is to say, when generating
a qemu core by kernel core dumper, we could call kvm to extract the relevant vmcs
information into an elf note instead of VMCSINFO and the whole vmcs regions.


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

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

[zhangyanfei]

于 2012年04月11日 16:56, Avi Kivity 写道:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash> rd -p 1cba8c0 1000
>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>          ......
> 
> Would be nicer to have a simple binary encoding <field> <offset> instead
> of this.

Agreed.

> 
>> TODO:
>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>      into vmcore.
>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>      and crash gcore.
> 
> 
> Seems excessive.  Why do you want vmcs information in qemu cores?  A
> qemu crash is very rarely related to kvm, let alone the vmcs.  I
> understand that you may want it in a kernel core dump, though I've never
> needed to myself.  Can you outline a case where this data was needed?
> 

If a qemu process comes to a fatal error that causes itself to be core dumped
by kernel, the running guest based on the qemu process will be included in that
qemu core file. But with no vmcsinfo information in qemu core file, we could not
get the guest's states(registers' values), then we could not make a complete
guest vmcore.

>>   3. Dump guest image from the qemu-process core file into a vmcore.
> 
> For this perhaps a different approach is better - modify the core dumper
> to call kvm to extract the relevant vmcs information into an elf note. 
> This way there is no need to reconstruct the guest data from the
> offsets.  It's also more reliable, since vmread can access cached fields
> that direct memory access cannot.
> 

Does this approach is a replacement for TODO 2 ? That is to say, when generating
a qemu core by kernel core dumper, we could call kvm to extract the relevant vmcs
information into an elf note instead of VMCSINFO and the whole vmcs regions.


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

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

[Joerg Roedel]

Hi,

On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
> The problem is that VMCS internal is hidden by Intel in its
> specification. So, we reverse engineering it in the way implemented in
> this patch set.

Have you made sure this layout is the same on all uarchitectures that
implment VMX?


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

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

[Joerg Roedel]

Hi,

On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
> The problem is that VMCS internal is hidden by Intel in its
> specification. So, we reverse engineering it in the way implemented in
> this patch set.

Have you made sure this layout is the same on all uarchitectures that
implment VMX?


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

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

[Joerg Roedel]

Hi,

On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
> The problem is that VMCS internal is hidden by Intel in its
> specification. So, we reverse engineering it in the way implemented in
> this patch set.

Have you made sure this layout is the same on all uarchitectures that
implment VMX?


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632


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

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[zhangyanfei]

于 2012年04月11日 16:48, Avi Kivity 写道:
> On 04/11/2012 04:50 AM, zhangyanfei wrote:
>> This patch is to implement the feature that at initialization of
>> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
>> and encoded offsets of VMCS fields. The reason why we put the
>> VMCSINFO processing at the initialization of kvm_intel module
>> is that it's dangerous to rob VMX resources while kvm module is
>> loaded.
> 
> Maybe it should be done by a separate module.
> 

If we put vmcsinfo processing at the initialization of kvm_intel module,
as soon as the kvm_intel module is loaded, VMCSINFO is filled. And it is
because vmcsinfo processing is at the initialization of kvm_intel module,
no kvm guests are running, so it will not rob any VMX resources.

If it is done by a separate module, I am afraid this module may not be
loaded when the kernel needs VMCSINFO.

>> +
>> +	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
>> +	vmcs_load(vmcs);
> 
> Should do this after writing into the vmcs directly (vmcs_load() may
> cache some information for vmcs_read()).
>

Hmm, thanks for pointing this.

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[zhangyanfei]

于 2012年04月11日 16:48, Avi Kivity 写道:
> On 04/11/2012 04:50 AM, zhangyanfei wrote:
>> This patch is to implement the feature that at initialization of
>> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
>> and encoded offsets of VMCS fields. The reason why we put the
>> VMCSINFO processing at the initialization of kvm_intel module
>> is that it's dangerous to rob VMX resources while kvm module is
>> loaded.
> 
> Maybe it should be done by a separate module.
> 

If we put vmcsinfo processing at the initialization of kvm_intel module,
as soon as the kvm_intel module is loaded, VMCSINFO is filled. And it is
because vmcsinfo processing is at the initialization of kvm_intel module,
no kvm guests are running, so it will not rob any VMX resources.

If it is done by a separate module, I am afraid this module may not be
loaded when the kernel needs VMCSINFO.

>> +
>> +	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
>> +	vmcs_load(vmcs);
> 
> Should do this after writing into the vmcs directly (vmcs_load() may
> cache some information for vmcs_read()).
>

Hmm, thanks for pointing this.


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

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[zhangyanfei]

于 2012年04月11日 16:48, Avi Kivity 写道:
> On 04/11/2012 04:50 AM, zhangyanfei wrote:
>> This patch is to implement the feature that at initialization of
>> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
>> and encoded offsets of VMCS fields. The reason why we put the
>> VMCSINFO processing at the initialization of kvm_intel module
>> is that it's dangerous to rob VMX resources while kvm module is
>> loaded.
> 
> Maybe it should be done by a separate module.
> 

If we put vmcsinfo processing at the initialization of kvm_intel module,
as soon as the kvm_intel module is loaded, VMCSINFO is filled. And it is
because vmcsinfo processing is at the initialization of kvm_intel module,
no kvm guests are running, so it will not rob any VMX resources.

If it is done by a separate module, I am afraid this module may not be
loaded when the kernel needs VMCSINFO.

>> +
>> +	kvm_cpu_vmxon(__pa(per_cpu(vmxarea, raw_smp_processor_id())));
>> +	vmcs_load(vmcs);
> 
> Should do this after writing into the vmcs directly (vmcs_load() may
> cache some information for vmcs_read()).
>

Hmm, thanks for pointing this.


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

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

[Avi Kivity]

On 04/11/2012 01:21 PM, Joerg Roedel wrote:
> Hi,
>
> On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
> > The problem is that VMCS internal is hidden by Intel in its
> > specification. So, we reverse engineering it in the way implemented in
> > this patch set.
>
> Have you made sure this layout is the same on all uarchitectures that
> implment VMX?

He's determining the layout at runtime.  It should even work with kvm's
vmx implementation.

It's vulnerable to two issues:
- fields that are cached in the processor and not flushed to memory
(perhaps just make sure to VMXOFF before dumping memory)
- fields that are encoded differently in memory than VMREAD/VMWRITE

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/11/2012 01:21 PM, Joerg Roedel wrote:
> Hi,
>
> On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
> > The problem is that VMCS internal is hidden by Intel in its
> > specification. So, we reverse engineering it in the way implemented in
> > this patch set.
>
> Have you made sure this layout is the same on all uarchitectures that
> implment VMX?

He's determining the layout at runtime.  It should even work with kvm's
vmx implementation.

It's vulnerable to two issues:
- fields that are cached in the processor and not flushed to memory
(perhaps just make sure to VMXOFF before dumping memory)
- fields that are encoded differently in memory than VMREAD/VMWRITE

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/11/2012 01:21 PM, Joerg Roedel wrote:
> Hi,
>
> On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
> > The problem is that VMCS internal is hidden by Intel in its
> > specification. So, we reverse engineering it in the way implemented in
> > this patch set.
>
> Have you made sure this layout is the same on all uarchitectures that
> implment VMX?

He's determining the layout at runtime.  It should even work with kvm's
vmx implementation.

It's vulnerable to two issues:
- fields that are cached in the processor and not flushed to memory
(perhaps just make sure to VMXOFF before dumping memory)
- fields that are encoded differently in memory than VMREAD/VMWRITE

-- 
error compiling committee.c: too many arguments to function


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

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

[zhangyanfei]

于 2012年04月11日 18:21, Joerg Roedel 写道:
> Hi,
> 
> On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
>> The problem is that VMCS internal is hidden by Intel in its
>> specification. So, we reverse engineering it in the way implemented in
>> this patch set.
> 
> Have you made sure this layout is the same on all uarchitectures that
> implment VMX?
> 
> 
> 	Joerg
> 

The layout differs from each other in different VMCS revision identifiers. 
The VMCS revision identifier is contained at the first 32 bits of the VMCS
region. And the VMCS revision identifiers may differ from different architectures.

for example, there are two processors below:
Processor 1: Intel(R) Xeon(R) CPU E7540  @ 2.00GHz with 24 cores
REVISION_ID=e
FIELD(PIN_BASED_VM_EXEC_CONTROL)=05540550
FIELD(CPU_BASED_VM_EXEC_CONTROL)=05440540
FIELD(SECONDARY_VM_EXEC_CONTROL)=054c0548
FIELD(VM_EXIT_CONTROLS) =        057c0578
FIELD(VM_ENTRY_CONTROLS)=        05940590
......

Processor 2: Intel(R) Core(TM)2 Duo CPU E7500  @ 2.93GHz
REVISION_ID=d
FIELD(PIN_BASED_VM_EXEC_CONTROL)=01840180
FIELD(CPU_BASED_VM_EXEC_CONTROL)=01940190
FIELD(SECONDARY_VM_EXEC_CONTROL)=0fe40fe0
FIELD(VM_EXIT_CONTROLS) =        01e401e0
FIELD(VM_ENTRY_CONTROLS)=        03140310

The purpose to get the VMCSINFO of one architecture is for guest debugging that was
running on the same architecture, so there is no problem the layouts differ from different
architectures.

Thanks
Zhang Yanfei

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

[zhangyanfei]

于 2012年04月11日 18:21, Joerg Roedel 写道:
> Hi,
> 
> On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
>> The problem is that VMCS internal is hidden by Intel in its
>> specification. So, we reverse engineering it in the way implemented in
>> this patch set.
> 
> Have you made sure this layout is the same on all uarchitectures that
> implment VMX?
> 
> 
> 	Joerg
> 

The layout differs from each other in different VMCS revision identifiers. 
The VMCS revision identifier is contained at the first 32 bits of the VMCS
region. And the VMCS revision identifiers may differ from different architectures.

for example, there are two processors below:
Processor 1: Intel(R) Xeon(R) CPU E7540  @ 2.00GHz with 24 cores
REVISION_ID=e
FIELD(PIN_BASED_VM_EXEC_CONTROL)=05540550
FIELD(CPU_BASED_VM_EXEC_CONTROL)=05440540
FIELD(SECONDARY_VM_EXEC_CONTROL)=054c0548
FIELD(VM_EXIT_CONTROLS) =        057c0578
FIELD(VM_ENTRY_CONTROLS)=        05940590
......

Processor 2: Intel(R) Core(TM)2 Duo CPU E7500  @ 2.93GHz
REVISION_ID=d
FIELD(PIN_BASED_VM_EXEC_CONTROL)=01840180
FIELD(CPU_BASED_VM_EXEC_CONTROL)=01940190
FIELD(SECONDARY_VM_EXEC_CONTROL)=0fe40fe0
FIELD(VM_EXIT_CONTROLS) =        01e401e0
FIELD(VM_ENTRY_CONTROLS)=        03140310

The purpose to get the VMCSINFO of one architecture is for guest debugging that was
running on the same architecture, so there is no problem the layouts differ from different
architectures.

Thanks
Zhang Yanfei


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

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

[zhangyanfei]

于 2012年04月11日 18:21, Joerg Roedel 写道:
> Hi,
> 
> On Wed, Apr 11, 2012 at 09:39:43AM +0800, zhangyanfei wrote:
>> The problem is that VMCS internal is hidden by Intel in its
>> specification. So, we reverse engineering it in the way implemented in
>> this patch set.
> 
> Have you made sure this layout is the same on all uarchitectures that
> implment VMX?
> 
> 
> 	Joerg
> 

The layout differs from each other in different VMCS revision identifiers. 
The VMCS revision identifier is contained at the first 32 bits of the VMCS
region. And the VMCS revision identifiers may differ from different architectures.

for example, there are two processors below:
Processor 1: Intel(R) Xeon(R) CPU E7540  @ 2.00GHz with 24 cores
REVISION_ID=e
FIELD(PIN_BASED_VM_EXEC_CONTROL)=05540550
FIELD(CPU_BASED_VM_EXEC_CONTROL)=05440540
FIELD(SECONDARY_VM_EXEC_CONTROL)=054c0548
FIELD(VM_EXIT_CONTROLS) =        057c0578
FIELD(VM_ENTRY_CONTROLS)=        05940590
......

Processor 2: Intel(R) Core(TM)2 Duo CPU E7500  @ 2.93GHz
REVISION_ID=d
FIELD(PIN_BASED_VM_EXEC_CONTROL)=01840180
FIELD(CPU_BASED_VM_EXEC_CONTROL)=01940190
FIELD(SECONDARY_VM_EXEC_CONTROL)=0fe40fe0
FIELD(VM_EXIT_CONTROLS) =        01e401e0
FIELD(VM_ENTRY_CONTROLS)=        03140310

The purpose to get the VMCSINFO of one architecture is for guest debugging that was
running on the same architecture, so there is no problem the layouts differ from different
architectures.

Thanks
Zhang Yanfei


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

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

[Avi Kivity]

On 04/11/2012 01:12 PM, zhangyanfei wrote:
> > 
> >> TODO:
> >>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
> >>      into vmcore.
> >>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
> >>      core file. To do this, we will modify kernel core dumper, gdb gcore
> >>      and crash gcore.
> > 
> > 
> > Seems excessive.  Why do you want vmcs information in qemu cores?  A
> > qemu crash is very rarely related to kvm, let alone the vmcs.  I
> > understand that you may want it in a kernel core dump, though I've never
> > needed to myself.  Can you outline a case where this data was needed?
> > 
>
> If a qemu process comes to a fatal error that causes itself to be core dumped
> by kernel, the running guest based on the qemu process will be included in that
> qemu core file. But with no vmcsinfo information in qemu core file, we could not
> get the guest's states(registers' values), then we could not make a complete
> guest vmcore.

We can't anyway.  Many registers (GPRs except RSP, fpu) are not stored
in the VMCS, but in kvm data structures.

So for this case we'd want a kvm callback to execute (that would make it
work cross vendor, too).

>
> >>   3. Dump guest image from the qemu-process core file into a vmcore.
> > 
> > For this perhaps a different approach is better - modify the core dumper
> > to call kvm to extract the relevant vmcs information into an elf note. 
> > This way there is no need to reconstruct the guest data from the
> > offsets.  It's also more reliable, since vmread can access cached fields
> > that direct memory access cannot.
> > 
>
> Does this approach is a replacement for TODO 2 ? That is to say, when generating
> a qemu core by kernel core dumper, we could call kvm to extract the relevant vmcs
> information into an elf note instead of VMCSINFO and the whole vmcs regions.

Yes.  I'm not convinced it's important though.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/11/2012 01:12 PM, zhangyanfei wrote:
> > 
> >> TODO:
> >>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
> >>      into vmcore.
> >>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
> >>      core file. To do this, we will modify kernel core dumper, gdb gcore
> >>      and crash gcore.
> > 
> > 
> > Seems excessive.  Why do you want vmcs information in qemu cores?  A
> > qemu crash is very rarely related to kvm, let alone the vmcs.  I
> > understand that you may want it in a kernel core dump, though I've never
> > needed to myself.  Can you outline a case where this data was needed?
> > 
>
> If a qemu process comes to a fatal error that causes itself to be core dumped
> by kernel, the running guest based on the qemu process will be included in that
> qemu core file. But with no vmcsinfo information in qemu core file, we could not
> get the guest's states(registers' values), then we could not make a complete
> guest vmcore.

We can't anyway.  Many registers (GPRs except RSP, fpu) are not stored
in the VMCS, but in kvm data structures.

So for this case we'd want a kvm callback to execute (that would make it
work cross vendor, too).

>
> >>   3. Dump guest image from the qemu-process core file into a vmcore.
> > 
> > For this perhaps a different approach is better - modify the core dumper
> > to call kvm to extract the relevant vmcs information into an elf note. 
> > This way there is no need to reconstruct the guest data from the
> > offsets.  It's also more reliable, since vmread can access cached fields
> > that direct memory access cannot.
> > 
>
> Does this approach is a replacement for TODO 2 ? That is to say, when generating
> a qemu core by kernel core dumper, we could call kvm to extract the relevant vmcs
> information into an elf note instead of VMCSINFO and the whole vmcs regions.

Yes.  I'm not convinced it's important though.

-- 
error compiling committee.c: too many arguments to function


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

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[Avi Kivity]

On 04/11/2012 01:34 PM, zhangyanfei wrote:
> 于 2012年04月11日 16:48, Avi Kivity 写道:
> > On 04/11/2012 04:50 AM, zhangyanfei wrote:
> >> This patch is to implement the feature that at initialization of
> >> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
> >> and encoded offsets of VMCS fields. The reason why we put the
> >> VMCSINFO processing at the initialization of kvm_intel module
> >> is that it's dangerous to rob VMX resources while kvm module is
> >> loaded.
> > 
> > Maybe it should be done by a separate module.
> > 
>
> If we put vmcsinfo processing at the initialization of kvm_intel module,
> as soon as the kvm_intel module is loaded, VMCSINFO is filled. And it is
> because vmcsinfo processing is at the initialization of kvm_intel module,
> no kvm guests are running, so it will not rob any VMX resources.
>
> If it is done by a separate module, I am afraid this module may not be
> loaded when the kernel needs VMCSINFO.
>

You can make the module autoload when the vmx cpufeature is detected. 
But then there is an ordering problem wrt kvm-intel.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[Avi Kivity]

On 04/11/2012 01:34 PM, zhangyanfei wrote:
> 于 2012年04月11日 16:48, Avi Kivity 写道:
> > On 04/11/2012 04:50 AM, zhangyanfei wrote:
> >> This patch is to implement the feature that at initialization of
> >> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
> >> and encoded offsets of VMCS fields. The reason why we put the
> >> VMCSINFO processing at the initialization of kvm_intel module
> >> is that it's dangerous to rob VMX resources while kvm module is
> >> loaded.
> > 
> > Maybe it should be done by a separate module.
> > 
>
> If we put vmcsinfo processing at the initialization of kvm_intel module,
> as soon as the kvm_intel module is loaded, VMCSINFO is filled. And it is
> because vmcsinfo processing is at the initialization of kvm_intel module,
> no kvm guests are running, so it will not rob any VMX resources.
>
> If it is done by a separate module, I am afraid this module may not be
> loaded when the kernel needs VMCSINFO.
>

You can make the module autoload when the vmx cpufeature is detected. 
But then there is an ordering problem wrt kvm-intel.

-- 
error compiling committee.c: too many arguments to function


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

Re: [PATCH 2/4] KVM: VMX: Add functions to fill VMCSINFO

[Avi Kivity]

On 04/11/2012 01:34 PM, zhangyanfei wrote:
> 于 2012年04月11日 16:48, Avi Kivity 写道:
> > On 04/11/2012 04:50 AM, zhangyanfei wrote:
> >> This patch is to implement the feature that at initialization of
> >> kvm_intel module, fills VMCSINFO with a VMCS revision identifier,
> >> and encoded offsets of VMCS fields. The reason why we put the
> >> VMCSINFO processing at the initialization of kvm_intel module
> >> is that it's dangerous to rob VMX resources while kvm module is
> >> loaded.
> > 
> > Maybe it should be done by a separate module.
> > 
>
> If we put vmcsinfo processing at the initialization of kvm_intel module,
> as soon as the kvm_intel module is loaded, VMCSINFO is filled. And it is
> because vmcsinfo processing is at the initialization of kvm_intel module,
> no kvm guests are running, so it will not rob any VMX resources.
>
> If it is done by a separate module, I am afraid this module may not be
> loaded when the kernel needs VMCSINFO.
>

You can make the module autoload when the vmx cpufeature is detected. 
But then there is an ordering problem wrt kvm-intel.

-- 
error compiling committee.c: too many arguments to function


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

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[Greg KH]

On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
> This patch creates sysfs file to export where VMCSINFO is allocated,
> as below:
>         $ cat /sys/kernel/vmcsinfo
>         1cb88a0 2000
> number on the left-hand side is the physical address of VMCSINFO,
> while the one on the right-hand side is the max size of VMCSINFO.

Ick, why do you have 2 values in one sysfs file, that's not nice, or
good.

What's wrong with 2 different files?

Also, any new sysfs file you add needs to also have a Documentation/ABI
entry added as well.

But we can't accept this as-is, sorry, please split it up into 2 files.

greg k-h

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[Greg KH]

On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
> This patch creates sysfs file to export where VMCSINFO is allocated,
> as below:
>         $ cat /sys/kernel/vmcsinfo
>         1cb88a0 2000
> number on the left-hand side is the physical address of VMCSINFO,
> while the one on the right-hand side is the max size of VMCSINFO.

Ick, why do you have 2 values in one sysfs file, that's not nice, or
good.

What's wrong with 2 different files?

Also, any new sysfs file you add needs to also have a Documentation/ABI
entry added as well.

But we can't accept this as-is, sorry, please split it up into 2 files.

greg k-h

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[Greg KH]

On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
> This patch creates sysfs file to export where VMCSINFO is allocated,
> as below:
>         $ cat /sys/kernel/vmcsinfo
>         1cb88a0 2000
> number on the left-hand side is the physical address of VMCSINFO,
> while the one on the right-hand side is the max size of VMCSINFO.

Ick, why do you have 2 values in one sysfs file, that's not nice, or
good.

What's wrong with 2 different files?

Also, any new sysfs file you add needs to also have a Documentation/ABI
entry added as well.

But we can't accept this as-is, sorry, please split it up into 2 files.

greg k-h

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

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[zhangyanfei]

于 2012年04月13日 07:00, Greg KH 写道:
> On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
>> This patch creates sysfs file to export where VMCSINFO is allocated,
>> as below:
>>         $ cat /sys/kernel/vmcsinfo
>>         1cb88a0 2000
>> number on the left-hand side is the physical address of VMCSINFO,
>> while the one on the right-hand side is the max size of VMCSINFO.
> 
> Ick, why do you have 2 values in one sysfs file, that's not nice, or
> good.
> 
> What's wrong with 2 different files?
> 

The reason why I put the 2 values in one sysfs file is that there is a similar
file 'vmcoreinfo' in sysfs.
        # cat /sys/kernel/vmcoreinfo 
        1d75380 1000
Nothing wrong with two different files, I just wanted to export the vmcsinfo
with the interface that is the same as vmcoreinfo. So later in kexec-tools,
vmcsinfo note information will be handled in a very similar way as vmcoreinfo
note information.

> Also, any new sysfs file you add needs to also have a Documentation/ABI
> entry added as well.

Sorry for missing this. I will add it in next version of patch.

> 
> But we can't accept this as-is, sorry, please split it up into 2 files.
>
 
Thanks
Zhang Yanfei

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[zhangyanfei]

于 2012年04月13日 07:00, Greg KH 写道:
> On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
>> This patch creates sysfs file to export where VMCSINFO is allocated,
>> as below:
>>         $ cat /sys/kernel/vmcsinfo
>>         1cb88a0 2000
>> number on the left-hand side is the physical address of VMCSINFO,
>> while the one on the right-hand side is the max size of VMCSINFO.
> 
> Ick, why do you have 2 values in one sysfs file, that's not nice, or
> good.
> 
> What's wrong with 2 different files?
> 

The reason why I put the 2 values in one sysfs file is that there is a similar
file 'vmcoreinfo' in sysfs.
        # cat /sys/kernel/vmcoreinfo 
        1d75380 1000
Nothing wrong with two different files, I just wanted to export the vmcsinfo
with the interface that is the same as vmcoreinfo. So later in kexec-tools,
vmcsinfo note information will be handled in a very similar way as vmcoreinfo
note information.

> Also, any new sysfs file you add needs to also have a Documentation/ABI
> entry added as well.

Sorry for missing this. I will add it in next version of patch.

> 
> But we can't accept this as-is, sorry, please split it up into 2 files.
>
 
Thanks
Zhang Yanfei


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

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[Greg KH]

On Tue, Apr 17, 2012 at 09:52:42AM +0800, zhangyanfei wrote:
> 于 2012年04月13日 07:00, Greg KH 写道:
> > On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
> >> This patch creates sysfs file to export where VMCSINFO is allocated,
> >> as below:
> >>         $ cat /sys/kernel/vmcsinfo
> >>         1cb88a0 2000
> >> number on the left-hand side is the physical address of VMCSINFO,
> >> while the one on the right-hand side is the max size of VMCSINFO.
> > 
> > Ick, why do you have 2 values in one sysfs file, that's not nice, or
> > good.
> > 
> > What's wrong with 2 different files?
> > 
> 
> The reason why I put the 2 values in one sysfs file is that there is a similar
> file 'vmcoreinfo' in sysfs.
>         # cat /sys/kernel/vmcoreinfo 
>         1d75380 1000

Then that should be fixed as well, using two different file names now :(

thanks,

greg k-h

Re: [PATCH 3/4] ksysfs: export VMCSINFO via sysfs

[Greg KH]

On Tue, Apr 17, 2012 at 09:52:42AM +0800, zhangyanfei wrote:
> 于 2012年04月13日 07:00, Greg KH 写道:
> > On Wed, Apr 11, 2012 at 09:57:34AM +0800, zhangyanfei wrote:
> >> This patch creates sysfs file to export where VMCSINFO is allocated,
> >> as below:
> >>         $ cat /sys/kernel/vmcsinfo
> >>         1cb88a0 2000
> >> number on the left-hand side is the physical address of VMCSINFO,
> >> while the one on the right-hand side is the max size of VMCSINFO.
> > 
> > Ick, why do you have 2 values in one sysfs file, that's not nice, or
> > good.
> > 
> > What's wrong with 2 different files?
> > 
> 
> The reason why I put the 2 values in one sysfs file is that there is a similar
> file 'vmcoreinfo' in sysfs.
>         # cat /sys/kernel/vmcoreinfo 
>         1d75380 1000

Then that should be fixed as well, using two different file names now :(

thanks,

greg k-h

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

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

[Avi Kivity]

On 04/11/2012 04:39 AM, zhangyanfei wrote:
> This patch set exports offsets of VMCS fields as note information for
> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> runtime state of guest machine image, such as registers, in host
> machine's crash dump as VMCS format. The problem is that VMCS
> internal is hidden by Intel in its specification. So, we reverse
> engineering it in the way implemented in this patch set. Please note
> that this processing never affects any existing kvm logic. The
> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>
> Here is an example:
> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>
> $cat /sys/kernel/vmcsinfo
> 1cba8c0 2000
>
> crash> rd -p 1cba8c0 1000
>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>          ......
>
> TODO:
>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>      into vmcore.
>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>      core file. To do this, we will modify kernel core dumper, gdb gcore
>      and crash gcore.
>   3. Dump guest image from the qemu-process core file into a vmcore.
>

Taking a step back, can you describe the problem scenario you're fixing
here?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/11/2012 04:39 AM, zhangyanfei wrote:
> This patch set exports offsets of VMCS fields as note information for
> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> runtime state of guest machine image, such as registers, in host
> machine's crash dump as VMCS format. The problem is that VMCS
> internal is hidden by Intel in its specification. So, we reverse
> engineering it in the way implemented in this patch set. Please note
> that this processing never affects any existing kvm logic. The
> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>
> Here is an example:
> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>
> $cat /sys/kernel/vmcsinfo
> 1cba8c0 2000
>
> crash> rd -p 1cba8c0 1000
>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>          ......
>
> TODO:
>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>      into vmcore.
>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>      core file. To do this, we will modify kernel core dumper, gdb gcore
>      and crash gcore.
>   3. Dump guest image from the qemu-process core file into a vmcore.
>

Taking a step back, can you describe the problem scenario you're fixing
here?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/11/2012 04:39 AM, zhangyanfei wrote:
> This patch set exports offsets of VMCS fields as note information for
> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> runtime state of guest machine image, such as registers, in host
> machine's crash dump as VMCS format. The problem is that VMCS
> internal is hidden by Intel in its specification. So, we reverse
> engineering it in the way implemented in this patch set. Please note
> that this processing never affects any existing kvm logic. The
> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>
> Here is an example:
> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>
> $cat /sys/kernel/vmcsinfo
> 1cba8c0 2000
>
> crash> rd -p 1cba8c0 1000
>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>          ......
>
> TODO:
>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>      into vmcore.
>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>      core file. To do this, we will modify kernel core dumper, gdb gcore
>      and crash gcore.
>   3. Dump guest image from the qemu-process core file into a vmcore.
>

Taking a step back, can you describe the problem scenario you're fixing
here?

-- 
error compiling committee.c: too many arguments to function


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

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

[zhangyanfei]

于 2012年04月17日 15:44, Avi Kivity 写道:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash> rd -p 1cba8c0 1000
>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>          ......
>>
>> TODO:
>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>      into vmcore.
>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>      and crash gcore.
>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>
> 
> Taking a step back, can you describe the problem scenario you're fixing
> here?
> 
Considering two scenarios below:
1. Host panics, guests running on that host will also be dumped into
   host's vmcore.
2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
   its coresponding guest will be included in the core file.

We want to create the guest machine's crash dump from host machine's vmcore
or qemu process's core file. Unfortunately, we cannot get the guest's registers
values in both scenarios.

For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
in VMCS region. But VMCS internal is hidden by Intel specification. So this
patch set aims to get offsets of fields in VMCS region and export it as note
information for kdump. 

For scenario 2, we also want the guest's registers values to be dumped into
qemu process's core file when qemu process crashes. This is the task of TODO-list 2.

Is this what you want?

Thanks
Zhang Yanfei

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

[zhangyanfei]

于 2012年04月17日 15:44, Avi Kivity 写道:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash> rd -p 1cba8c0 1000
>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>          ......
>>
>> TODO:
>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>      into vmcore.
>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>      and crash gcore.
>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>
> 
> Taking a step back, can you describe the problem scenario you're fixing
> here?
> 
Considering two scenarios below:
1. Host panics, guests running on that host will also be dumped into
   host's vmcore.
2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
   its coresponding guest will be included in the core file.

We want to create the guest machine's crash dump from host machine's vmcore
or qemu process's core file. Unfortunately, we cannot get the guest's registers
values in both scenarios.

For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
in VMCS region. But VMCS internal is hidden by Intel specification. So this
patch set aims to get offsets of fields in VMCS region and export it as note
information for kdump. 

For scenario 2, we also want the guest's registers values to be dumped into
qemu process's core file when qemu process crashes. This is the task of TODO-list 2.

Is this what you want?

Thanks
Zhang Yanfei


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

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

[zhangyanfei]

于 2012年04月17日 15:44, Avi Kivity 写道:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash> rd -p 1cba8c0 1000
>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>          ......
>>
>> TODO:
>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>      into vmcore.
>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>      and crash gcore.
>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>
> 
> Taking a step back, can you describe the problem scenario you're fixing
> here?
> 
Considering two scenarios below:
1. Host panics, guests running on that host will also be dumped into
   host's vmcore.
2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
   its coresponding guest will be included in the core file.

We want to create the guest machine's crash dump from host machine's vmcore
or qemu process's core file. Unfortunately, we cannot get the guest's registers
values in both scenarios.

For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
in VMCS region. But VMCS internal is hidden by Intel specification. So this
patch set aims to get offsets of fields in VMCS region and export it as note
information for kdump. 

For scenario 2, we also want the guest's registers values to be dumped into
qemu process's core file when qemu process crashes. This is the task of TODO-list 2.

Is this what you want?

Thanks
Zhang Yanfei


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

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

[Avi Kivity]

On 04/17/2012 01:51 PM, zhangyanfei wrote:
> 于 2012年04月17日 15:44, Avi Kivity 写道:
> > On 04/11/2012 04:39 AM, zhangyanfei wrote:
> >> This patch set exports offsets of VMCS fields as note information for
> >> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> >> runtime state of guest machine image, such as registers, in host
> >> machine's crash dump as VMCS format. The problem is that VMCS
> >> internal is hidden by Intel in its specification. So, we reverse
> >> engineering it in the way implemented in this patch set. Please note
> >> that this processing never affects any existing kvm logic. The
> >> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
> >>
> >> Here is an example:
> >> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
> >>
> >> $cat /sys/kernel/vmcsinfo
> >> 1cba8c0 2000
> >>
> >> crash> rd -p 1cba8c0 1000
> >>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
> >>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
> >>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
> >>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
> >>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
> >>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
> >>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
> >>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
> >>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
> >>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
> >>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
> >>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
> >>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
> >>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
> >>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
> >>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
> >>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
> >>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
> >>          ......
> >>
> >> TODO:
> >>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
> >>      into vmcore.
> >>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
> >>      core file. To do this, we will modify kernel core dumper, gdb gcore
> >>      and crash gcore.
> >>   3. Dump guest image from the qemu-process core file into a vmcore.
> >>
> > 
> > Taking a step back, can you describe the problem scenario you're fixing
> > here?
> > 
> Considering two scenarios below:
> 1. Host panics, guests running on that host will also be dumped into
>    host's vmcore.
> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>    its coresponding guest will be included in the core file.
>
> We want to create the guest machine's crash dump from host machine's vmcore
> or qemu process's core file. Unfortunately, we cannot get the guest's registers
> values in both scenarios.
>
> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
> in VMCS region. But VMCS internal is hidden by Intel specification. So this
> patch set aims to get offsets of fields in VMCS region and export it as note
> information for kdump. 

Okay.  Do you expect it to help in debugging the crash?  Did you have
cases where it would help?

>
> For scenario 2, we also want the guest's registers values to be dumped into
> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.

Why?  If qemu crashed it is because of an internal qemu fault.  If any
guest registers were involved, they would have been decoded by qemu
previously and would be present in the stack trace (for example mmio
address/data).

> Is this what you want?
>

Yes.  I'm trying to understand if the feature would be useful in real life.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/17/2012 01:51 PM, zhangyanfei wrote:
> 于 2012年04月17日 15:44, Avi Kivity 写道:
> > On 04/11/2012 04:39 AM, zhangyanfei wrote:
> >> This patch set exports offsets of VMCS fields as note information for
> >> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> >> runtime state of guest machine image, such as registers, in host
> >> machine's crash dump as VMCS format. The problem is that VMCS
> >> internal is hidden by Intel in its specification. So, we reverse
> >> engineering it in the way implemented in this patch set. Please note
> >> that this processing never affects any existing kvm logic. The
> >> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
> >>
> >> Here is an example:
> >> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
> >>
> >> $cat /sys/kernel/vmcsinfo
> >> 1cba8c0 2000
> >>
> >> crash> rd -p 1cba8c0 1000
> >>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
> >>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
> >>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
> >>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
> >>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
> >>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
> >>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
> >>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
> >>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
> >>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
> >>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
> >>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
> >>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
> >>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
> >>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
> >>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
> >>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
> >>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
> >>          ......
> >>
> >> TODO:
> >>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
> >>      into vmcore.
> >>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
> >>      core file. To do this, we will modify kernel core dumper, gdb gcore
> >>      and crash gcore.
> >>   3. Dump guest image from the qemu-process core file into a vmcore.
> >>
> > 
> > Taking a step back, can you describe the problem scenario you're fixing
> > here?
> > 
> Considering two scenarios below:
> 1. Host panics, guests running on that host will also be dumped into
>    host's vmcore.
> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>    its coresponding guest will be included in the core file.
>
> We want to create the guest machine's crash dump from host machine's vmcore
> or qemu process's core file. Unfortunately, we cannot get the guest's registers
> values in both scenarios.
>
> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
> in VMCS region. But VMCS internal is hidden by Intel specification. So this
> patch set aims to get offsets of fields in VMCS region and export it as note
> information for kdump. 

Okay.  Do you expect it to help in debugging the crash?  Did you have
cases where it would help?

>
> For scenario 2, we also want the guest's registers values to be dumped into
> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.

Why?  If qemu crashed it is because of an internal qemu fault.  If any
guest registers were involved, they would have been decoded by qemu
previously and would be present in the stack trace (for example mmio
address/data).

> Is this what you want?
>

Yes.  I'm trying to understand if the feature would be useful in real life.

-- 
error compiling committee.c: too many arguments to function


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

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

[Avi Kivity]

On 04/17/2012 01:51 PM, zhangyanfei wrote:
> 于 2012年04月17日 15:44, Avi Kivity 写道:
> > On 04/11/2012 04:39 AM, zhangyanfei wrote:
> >> This patch set exports offsets of VMCS fields as note information for
> >> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
> >> runtime state of guest machine image, such as registers, in host
> >> machine's crash dump as VMCS format. The problem is that VMCS
> >> internal is hidden by Intel in its specification. So, we reverse
> >> engineering it in the way implemented in this patch set. Please note
> >> that this processing never affects any existing kvm logic. The
> >> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
> >>
> >> Here is an example:
> >> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
> >>
> >> $cat /sys/kernel/vmcsinfo
> >> 1cba8c0 2000
> >>
> >> crash> rd -p 1cba8c0 1000
> >>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
> >>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
> >>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
> >>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
> >>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
> >>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
> >>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
> >>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
> >>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
> >>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
> >>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
> >>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
> >>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
> >>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
> >>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
> >>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
> >>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
> >>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
> >>          ......
> >>
> >> TODO:
> >>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
> >>      into vmcore.
> >>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
> >>      core file. To do this, we will modify kernel core dumper, gdb gcore
> >>      and crash gcore.
> >>   3. Dump guest image from the qemu-process core file into a vmcore.
> >>
> > 
> > Taking a step back, can you describe the problem scenario you're fixing
> > here?
> > 
> Considering two scenarios below:
> 1. Host panics, guests running on that host will also be dumped into
>    host's vmcore.
> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>    its coresponding guest will be included in the core file.
>
> We want to create the guest machine's crash dump from host machine's vmcore
> or qemu process's core file. Unfortunately, we cannot get the guest's registers
> values in both scenarios.
>
> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
> in VMCS region. But VMCS internal is hidden by Intel specification. So this
> patch set aims to get offsets of fields in VMCS region and export it as note
> information for kdump. 

Okay.  Do you expect it to help in debugging the crash?  Did you have
cases where it would help?

>
> For scenario 2, we also want the guest's registers values to be dumped into
> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.

Why?  If qemu crashed it is because of an internal qemu fault.  If any
guest registers were involved, they would have been decoded by qemu
previously and would be present in the stack trace (for example mmio
address/data).

> Is this what you want?
>

Yes.  I'm trying to understand if the feature would be useful in real life.

-- 
error compiling committee.c: too many arguments to function


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

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

[Wen Congyang]

At 04/17/2012 06:59 PM, Avi Kivity Wrote:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>>>          ......
>>>>
>>>> TODO:
>>>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>>      into vmcore.
>>>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>>>      and crash gcore.
>>>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>>    host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>>    its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump. 
> 
> Okay.  Do you expect it to help in debugging the crash?  Did you have
> cases where it would help?
> 
>>
>> For scenario 2, we also want the guest's registers values to be dumped into
>> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
> 
> Why?  If qemu crashed it is because of an internal qemu fault.  If any
> guest registers were involved, they would have been decoded by qemu
> previously and would be present in the stack trace (for example mmio
> address/data).

Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
The guest registers are stored in the kernel, and qemu does not call
cpu_synchronize_state() to get guest register. So I donot understand
why the registers woubld be present int the stack trace...

Thanks
Wen Congyang

> 
>> Is this what you want?
>>
> 
> Yes.  I'm trying to understand if the feature would be useful in real life.
> 

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

[Wen Congyang]

At 04/17/2012 06:59 PM, Avi Kivity Wrote:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>>>          ......
>>>>
>>>> TODO:
>>>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>>      into vmcore.
>>>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>>>      and crash gcore.
>>>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>>    host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>>    its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump. 
> 
> Okay.  Do you expect it to help in debugging the crash?  Did you have
> cases where it would help?
> 
>>
>> For scenario 2, we also want the guest's registers values to be dumped into
>> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
> 
> Why?  If qemu crashed it is because of an internal qemu fault.  If any
> guest registers were involved, they would have been decoded by qemu
> previously and would be present in the stack trace (for example mmio
> address/data).

Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
The guest registers are stored in the kernel, and qemu does not call
cpu_synchronize_state() to get guest register. So I donot understand
why the registers woubld be present int the stack trace...

Thanks
Wen Congyang

> 
>> Is this what you want?
>>
> 
> Yes.  I'm trying to understand if the feature would be useful in real life.
> 


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

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

[Wen Congyang]

At 04/17/2012 06:59 PM, Avi Kivity Wrote:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>>>          ......
>>>>
>>>> TODO:
>>>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>>      into vmcore.
>>>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>>>      and crash gcore.
>>>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>>    host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>>    its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump. 
> 
> Okay.  Do you expect it to help in debugging the crash?  Did you have
> cases where it would help?
> 
>>
>> For scenario 2, we also want the guest's registers values to be dumped into
>> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
> 
> Why?  If qemu crashed it is because of an internal qemu fault.  If any
> guest registers were involved, they would have been decoded by qemu
> previously and would be present in the stack trace (for example mmio
> address/data).

Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
The guest registers are stored in the kernel, and qemu does not call
cpu_synchronize_state() to get guest register. So I donot understand
why the registers woubld be present int the stack trace...

Thanks
Wen Congyang

> 
>> Is this what you want?
>>
> 
> Yes.  I'm trying to understand if the feature would be useful in real life.
> 


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

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

[Avi Kivity]

On 04/17/2012 02:25 PM, Wen Congyang wrote:
> > 
> >>
> >> For scenario 2, we also want the guest's registers values to be dumped into
> >> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
> > 
> > Why?  If qemu crashed it is because of an internal qemu fault.  If any
> > guest registers were involved, they would have been decoded by qemu
> > previously and would be present in the stack trace (for example mmio
> > address/data).
>
> Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
> The guest registers are stored in the kernel, and qemu does not call
> cpu_synchronize_state() to get guest register. So I donot understand
> why the registers woubld be present int the stack trace...

There are two cases.  One case is where the problem was not caused
directly by guest action, for example a segmentation fault in the block
layer or the VNC server.  In this case the guest registers are immaterial.

The other case is where the problem was directly caused by guest action,
for example an mmio write to a device register triggered an error. In
this case kvm emulates the mmio instruction and returns KVM_EXIT_MMIO;
it can be seen in the kvm_run page.  The address/data pair is propagated
by the qemu memory core all the way to the device callback.  So the
instruction and register contents are unneeded for debugging the crash.

Is there a scenario where the guest registers help towards debugging a
qemu crash?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/17/2012 02:25 PM, Wen Congyang wrote:
> > 
> >>
> >> For scenario 2, we also want the guest's registers values to be dumped into
> >> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
> > 
> > Why?  If qemu crashed it is because of an internal qemu fault.  If any
> > guest registers were involved, they would have been decoded by qemu
> > previously and would be present in the stack trace (for example mmio
> > address/data).
>
> Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
> The guest registers are stored in the kernel, and qemu does not call
> cpu_synchronize_state() to get guest register. So I donot understand
> why the registers woubld be present int the stack trace...

There are two cases.  One case is where the problem was not caused
directly by guest action, for example a segmentation fault in the block
layer or the VNC server.  In this case the guest registers are immaterial.

The other case is where the problem was directly caused by guest action,
for example an mmio write to a device register triggered an error. In
this case kvm emulates the mmio instruction and returns KVM_EXIT_MMIO;
it can be seen in the kvm_run page.  The address/data pair is propagated
by the qemu memory core all the way to the device callback.  So the
instruction and register contents are unneeded for debugging the crash.

Is there a scenario where the guest registers help towards debugging a
qemu crash?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/17/2012 02:25 PM, Wen Congyang wrote:
> > 
> >>
> >> For scenario 2, we also want the guest's registers values to be dumped into
> >> qemu process's core file when qemu process crashes. This is the task of TODO-list 2.
> > 
> > Why?  If qemu crashed it is because of an internal qemu fault.  If any
> > guest registers were involved, they would have been decoded by qemu
> > previously and would be present in the stack trace (for example mmio
> > address/data).
>
> Hmm, IIRC, if qemu meets some critical error, it will call abort() or assert().
> The guest registers are stored in the kernel, and qemu does not call
> cpu_synchronize_state() to get guest register. So I donot understand
> why the registers woubld be present int the stack trace...

There are two cases.  One case is where the problem was not caused
directly by guest action, for example a segmentation fault in the block
layer or the VNC server.  In this case the guest registers are immaterial.

The other case is where the problem was directly caused by guest action,
for example an mmio write to a device register triggered an error. In
this case kvm emulates the mmio instruction and returns KVM_EXIT_MMIO;
it can be seen in the kvm_run page.  The address/data pair is propagated
by the qemu memory core all the way to the device callback.  So the
instruction and register contents are unneeded for debugging the crash.

Is there a scenario where the guest registers help towards debugging a
qemu crash?

-- 
error compiling committee.c: too many arguments to function


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

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

[Anthony Liguori]

On 04/17/2012 02:44 AM, Avi Kivity wrote:
> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS
>> internal is hidden by Intel in its specification. So, we reverse
>> engineering it in the way implemented in this patch set. Please note
>> that this processing never affects any existing kvm logic. The
>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>
>> Here is an example:
>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>
>> $cat /sys/kernel/vmcsinfo
>> 1cba8c0 2000
>>
>> crash>  rd -p 1cba8c0 1000
>>           1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>           1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>           1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>           1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>           1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>           1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>           1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>           1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>           1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>           1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>           1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>           1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>           1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>           1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>           1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>           1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>           1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>           1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>           ......
>>
>> TODO:
>>    1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>       into vmcore.
>>    2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>       core file. To do this, we will modify kernel core dumper, gdb gcore
>>       and crash gcore.
>>    3. Dump guest image from the qemu-process core file into a vmcore.
>>
>
> Taking a step back, can you describe the problem scenario you're fixing
> here?

Note that assuming that VMCS fields map to offsets within memory is not 
guaranteed to work for future processors.

There is no guarantee that fields won't be compressed or stored with inverted 
bit ordering.

Regards,

Anthony Liguori
>

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

[zhangyanfei]

于 2012年04月17日 18:59, Avi Kivity 写道:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>>>          ......
>>>>
>>>> TODO:
>>>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>>      into vmcore.
>>>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>>>      and crash gcore.
>>>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>>    host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>>    its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump. 
> 
> Okay.  Do you expect it to help in debugging the crash?  Did you have
> cases where it would help?
> 

Yes, I do expect it to help in debugging the crash.
Looking into host machine's crash dump, if we figure out the fact that the crash
had happend when some host's resource was requested and used by some guset machine.
Then, we surely want to look into the situation from guest machine's view.

Thanks
Zhang Yanfei

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

[zhangyanfei]

于 2012年04月17日 18:59, Avi Kivity 写道:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>>>          ......
>>>>
>>>> TODO:
>>>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>>      into vmcore.
>>>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>>>      and crash gcore.
>>>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>>    host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>>    its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump. 
> 
> Okay.  Do you expect it to help in debugging the crash?  Did you have
> cases where it would help?
> 

Yes, I do expect it to help in debugging the crash.
Looking into host machine's crash dump, if we figure out the fact that the crash
had happend when some host's resource was requested and used by some guset machine.
Then, we surely want to look into the situation from guest machine's view.

Thanks
Zhang Yanfei


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

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

[zhangyanfei]

于 2012年04月17日 18:59, Avi Kivity 写道:
> On 04/17/2012 01:51 PM, zhangyanfei wrote:
>> 于 2012年04月17日 15:44, Avi Kivity 写道:
>>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>>> This patch set exports offsets of VMCS fields as note information for
>>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>>> runtime state of guest machine image, such as registers, in host
>>>> machine's crash dump as VMCS format. The problem is that VMCS
>>>> internal is hidden by Intel in its specification. So, we reverse
>>>> engineering it in the way implemented in this patch set. Please note
>>>> that this processing never affects any existing kvm logic. The
>>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>>
>>>> Here is an example:
>>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>>
>>>> $cat /sys/kernel/vmcsinfo
>>>> 1cba8c0 2000
>>>>
>>>> crash> rd -p 1cba8c0 1000
>>>>          1cba8c0:  0000127b00000009 53434d5600000000   ....{.......VMCS
>>>>          1cba8d0:  000000004f464e49 4e4f495349564552   INFO....REVISION
>>>>          1cba8e0:  49460a643d44495f 5f4e495028444c45   _ID=d.FIELD(PIN_
>>>>          1cba8f0:  4d565f4445534142 4f435f434558455f   BASED_VM_EXEC_CO
>>>>          1cba900:  303d294c4f52544e 0a30383130343831   NTROL)=01840180.
>>>>          1cba910:  504328444c454946 5f44455341425f55   FIELD(CPU_BASED_
>>>>          1cba920:  5f434558455f4d56 294c4f52544e4f43   VM_EXEC_CONTROL)
>>>>          1cba930:  393130343931303d 28444c4549460a30   =01940190.FIELD(
>>>>          1cba940:  5241444e4f434553 4558455f4d565f59   SECONDARY_VM_EXE
>>>>          1cba950:  4f52544e4f435f43 30346566303d294c   C_CONTROL)=0fe40
>>>>          1cba960:  4c4549460a306566 4958455f4d562844   fe0.FIELD(VM_EXI
>>>>          1cba970:  4f52544e4f435f54 346531303d29534c   T_CONTROLS)=01e4
>>>>          1cba980:  4549460a30653130 4e455f4d5628444c   01e0.FIELD(VM_EN
>>>>          1cba990:  544e4f435f595254 33303d29534c4f52   TRY_CONTROLS)=03
>>>>          1cba9a0:  460a303133303431 45554728444c4549   140310.FIELD(GUE
>>>>          1cba9b0:  45535f53455f5453 3d29524f5443454c   ST_ES_SELECTOR)=
>>>>          1cba9c0:  4549460a30303530 545345554728444c   0500.FIELD(GUEST
>>>>          1cba9d0:  454c45535f53435f 35303d29524f5443   _CS_SELECTOR)=05
>>>>          ......
>>>>
>>>> TODO:
>>>>   1. In kexec-tools, get VMCSINFO via sysfs and dump it as note information
>>>>      into vmcore.
>>>>   2. Dump VMCS region of each guest vcpu and VMCSINFO into qemu-process
>>>>      core file. To do this, we will modify kernel core dumper, gdb gcore
>>>>      and crash gcore.
>>>>   3. Dump guest image from the qemu-process core file into a vmcore.
>>>>
>>>
>>> Taking a step back, can you describe the problem scenario you're fixing
>>> here?
>>>
>> Considering two scenarios below:
>> 1. Host panics, guests running on that host will also be dumped into
>>    host's vmcore.
>> 2. Qemu process is core dumped (by gdb gcore or kernel core dumper), and
>>    its coresponding guest will be included in the core file.
>>
>> We want to create the guest machine's crash dump from host machine's vmcore
>> or qemu process's core file. Unfortunately, we cannot get the guest's registers
>> values in both scenarios.
>>
>> For scenario 1, some key registers (CR0, CR3...) of the guest machine are stored
>> in VMCS region. But VMCS internal is hidden by Intel specification. So this
>> patch set aims to get offsets of fields in VMCS region and export it as note
>> information for kdump. 
> 
> Okay.  Do you expect it to help in debugging the crash?  Did you have
> cases where it would help?
> 

Yes, I do expect it to help in debugging the crash.
Looking into host machine's crash dump, if we figure out the fact that the crash
had happend when some host's resource was requested and used by some guset machine.
Then, we surely want to look into the situation from guest machine's view.

Thanks
Zhang Yanfei


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

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

[Avi Kivity]

On 04/18/2012 10:30 AM, zhangyanfei wrote:
> > 
> > Okay.  Do you expect it to help in debugging the crash?  Did you have
> > cases where it would help?
> > 
>
> Yes, I do expect it to help in debugging the crash.
> Looking into host machine's crash dump, if we figure out the fact that the crash
> had happend when some host's resource was requested and used by some guset machine.
> Then, we surely want to look into the situation from guest machine's view.
>
>

What type of resource?  Can you give an example?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/18/2012 10:30 AM, zhangyanfei wrote:
> > 
> > Okay.  Do you expect it to help in debugging the crash?  Did you have
> > cases where it would help?
> > 
>
> Yes, I do expect it to help in debugging the crash.
> Looking into host machine's crash dump, if we figure out the fact that the crash
> had happend when some host's resource was requested and used by some guset machine.
> Then, we surely want to look into the situation from guest machine's view.
>
>

What type of resource?  Can you give an example?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/18/2012 10:30 AM, zhangyanfei wrote:
> > 
> > Okay.  Do you expect it to help in debugging the crash?  Did you have
> > cases where it would help?
> > 
>
> Yes, I do expect it to help in debugging the crash.
> Looking into host machine's crash dump, if we figure out the fact that the crash
> had happend when some host's resource was requested and used by some guset machine.
> Then, we surely want to look into the situation from guest machine's view.
>
>

What type of resource?  Can you give an example?

-- 
error compiling committee.c: too many arguments to function


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

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

[zhangyanfei]

于 2012年04月18日 16:24, Avi Kivity 写道:
> On 04/18/2012 10:30 AM, zhangyanfei wrote:
>>>
>>> Okay.  Do you expect it to help in debugging the crash?  Did you have
>>> cases where it would help?
>>>
>>
>> Yes, I do expect it to help in debugging the crash.
>> Looking into host machine's crash dump, if we figure out the fact that the crash
>> had happend when some host's resource was requested and used by some guset machine.
>> Then, we surely want to look into the situation from guest machine's view.
>>
>>
> 
> What type of resource?  Can you give an example?
> 
Sorry. No concrete example for now.

We are developing this on a conservative policy and I have put the vmcs processing
in a new module in patch set v2 as you required. The new module is auto-loaded when
the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
this module will have no side effect on the running guests.

And one thing I have to stress is that, we can see guest image as crash dump from
guest machine's view if we have the vmcsinfo, this itself is useful.

Thanks
Zhang Yanfei

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

[zhangyanfei]

于 2012年04月18日 16:24, Avi Kivity 写道:
> On 04/18/2012 10:30 AM, zhangyanfei wrote:
>>>
>>> Okay.  Do you expect it to help in debugging the crash?  Did you have
>>> cases where it would help?
>>>
>>
>> Yes, I do expect it to help in debugging the crash.
>> Looking into host machine's crash dump, if we figure out the fact that the crash
>> had happend when some host's resource was requested and used by some guset machine.
>> Then, we surely want to look into the situation from guest machine's view.
>>
>>
> 
> What type of resource?  Can you give an example?
> 
Sorry. No concrete example for now.

We are developing this on a conservative policy and I have put the vmcs processing
in a new module in patch set v2 as you required. The new module is auto-loaded when
the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
this module will have no side effect on the running guests.

And one thing I have to stress is that, we can see guest image as crash dump from
guest machine's view if we have the vmcsinfo, this itself is useful.

Thanks
Zhang Yanfei


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

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

[zhangyanfei]

于 2012年04月18日 16:24, Avi Kivity 写道:
> On 04/18/2012 10:30 AM, zhangyanfei wrote:
>>>
>>> Okay.  Do you expect it to help in debugging the crash?  Did you have
>>> cases where it would help?
>>>
>>
>> Yes, I do expect it to help in debugging the crash.
>> Looking into host machine's crash dump, if we figure out the fact that the crash
>> had happend when some host's resource was requested and used by some guset machine.
>> Then, we surely want to look into the situation from guest machine's view.
>>
>>
> 
> What type of resource?  Can you give an example?
> 
Sorry. No concrete example for now.

We are developing this on a conservative policy and I have put the vmcs processing
in a new module in patch set v2 as you required. The new module is auto-loaded when
the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
this module will have no side effect on the running guests.

And one thing I have to stress is that, we can see guest image as crash dump from
guest machine's view if we have the vmcsinfo, this itself is useful.

Thanks
Zhang Yanfei


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

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

[Avi Kivity]

On 04/18/2012 12:49 PM, zhangyanfei wrote:
> >>
> > 
> > What type of resource?  Can you give an example?
> > 
> Sorry. No concrete example for now.
>
> We are developing this on a conservative policy and I have put the vmcs processing
> in a new module in patch set v2 as you required. The new module is auto-loaded when
> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
> this module will have no side effect on the running guests.
>
> And one thing I have to stress is that, we can see guest image as crash dump from
> guest machine's view if we have the vmcsinfo, this itself is useful.

Why is it useful?  Without a concrete example, it's hard to justify the
code bloat.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/18/2012 12:49 PM, zhangyanfei wrote:
> >>
> > 
> > What type of resource?  Can you give an example?
> > 
> Sorry. No concrete example for now.
>
> We are developing this on a conservative policy and I have put the vmcs processing
> in a new module in patch set v2 as you required. The new module is auto-loaded when
> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
> this module will have no side effect on the running guests.
>
> And one thing I have to stress is that, we can see guest image as crash dump from
> guest machine's view if we have the vmcsinfo, this itself is useful.

Why is it useful?  Without a concrete example, it's hard to justify the
code bloat.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/18/2012 12:49 PM, zhangyanfei wrote:
> >>
> > 
> > What type of resource?  Can you give an example?
> > 
> Sorry. No concrete example for now.
>
> We are developing this on a conservative policy and I have put the vmcs processing
> in a new module in patch set v2 as you required. The new module is auto-loaded when
> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
> this module will have no side effect on the running guests.
>
> And one thing I have to stress is that, we can see guest image as crash dump from
> guest machine's view if we have the vmcsinfo, this itself is useful.

Why is it useful?  Without a concrete example, it's hard to justify the
code bloat.

-- 
error compiling committee.c: too many arguments to function


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

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

[Avi Kivity]

On 04/17/2012 07:49 PM, Anthony Liguori wrote:
> On 04/17/2012 02:44 AM, Avi Kivity wrote:
>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>> This patch set exports offsets of VMCS fields as note information for
>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>> runtime state of guest machine image, such as registers, in host
>>> machine's crash dump as VMCS format. The problem is that VMCS
>>> internal is hidden by Intel in its specification. So, we reverse
>>> engineering it in the way implemented in this patch set. Please note
>>> that this processing never affects any existing kvm logic. The
>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>
>>> Here is an example:
>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>
>>> $cat /sys/kernel/vmcsinfo
>>> 1cba8c0 2000
>>>
>>> crash>  rd -p 1cba8c0 1000
>>>           1cba8c0:  0000127b00000009 53434d5600000000  
>>> ....{.......VMCS
>>>           1cba8d0:  000000004f464e49 4e4f495349564552  
>>> INFO....REVISION
>>>           1cba8e0:  49460a643d44495f 5f4e495028444c45  
>>> _ID=d.FIELD(PIN_
>>>           1cba8f0:  4d565f4445534142 4f435f434558455f  
>>> BASED_VM_EXEC_CO
>>>           1cba900:  303d294c4f52544e 0a30383130343831  
>>> NTROL)=01840180.
>>>           1cba910:  504328444c454946 5f44455341425f55  
>>> FIELD(CPU_BASED_
>>>           1cba920:  5f434558455f4d56 294c4f52544e4f43  
>>> VM_EXEC_CONTROL)
>>>           1cba930:  393130343931303d 28444c4549460a30  
>>> =01940190.FIELD(
>>>           1cba940:  5241444e4f434553 4558455f4d565f59  
>>> SECONDARY_VM_EXE
>>>           1cba950:  4f52544e4f435f43 30346566303d294c  
>>> C_CONTROL)=0fe40
>>>           1cba960:  4c4549460a306566 4958455f4d562844  
>>> fe0.FIELD(VM_EXI
>>>           1cba970:  4f52544e4f435f54 346531303d29534c  
>>> T_CONTROLS)=01e4
>>>           1cba980:  4549460a30653130 4e455f4d5628444c  
>>> 01e0.FIELD(VM_EN
>>>           1cba990:  544e4f435f595254 33303d29534c4f52  
>>> TRY_CONTROLS)=03
>>>           1cba9a0:  460a303133303431 45554728444c4549  
>>> 140310.FIELD(GUE
>>>           1cba9b0:  45535f53455f5453 3d29524f5443454c  
>>> ST_ES_SELECTOR)=
>>>           1cba9c0:  4549460a30303530 545345554728444c  
>>> 0500.FIELD(GUEST
>>>           1cba9d0:  454c45535f53435f 35303d29524f5443  
>>> _CS_SELECTOR)=05
>>>           ......
>>>
>>> TODO:
>>>    1. In kexec-tools, get VMCSINFO via sysfs and dump it as note
>>> information
>>>       into vmcore.
>>>    2. Dump VMCS region of each guest vcpu and VMCSINFO into
>>> qemu-process
>>>       core file. To do this, we will modify kernel core dumper, gdb
>>> gcore
>>>       and crash gcore.
>>>    3. Dump guest image from the qemu-process core file into a vmcore.
>>>
>>
>> Taking a step back, can you describe the problem scenario you're fixing
>> here?
>
> Note that assuming that VMCS fields map to offsets within memory is
> not guaranteed to work for future processors.
>
> There is no guarantee that fields won't be compressed or stored with
> inverted bit ordering.
>

Right; they're also not required to be in memory at all - the processor
can cache them, even for VMCSs that are not active at this time. 
Running VMXOFF at panic time can fix that, but you have to broadcast it
to all processors, probably using NMI...

Still, some information is better than nothing.  What I doubt is whether
that information will ever be used.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/17/2012 07:49 PM, Anthony Liguori wrote:
> On 04/17/2012 02:44 AM, Avi Kivity wrote:
>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>> This patch set exports offsets of VMCS fields as note information for
>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>> runtime state of guest machine image, such as registers, in host
>>> machine's crash dump as VMCS format. The problem is that VMCS
>>> internal is hidden by Intel in its specification. So, we reverse
>>> engineering it in the way implemented in this patch set. Please note
>>> that this processing never affects any existing kvm logic. The
>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>
>>> Here is an example:
>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>
>>> $cat /sys/kernel/vmcsinfo
>>> 1cba8c0 2000
>>>
>>> crash>  rd -p 1cba8c0 1000
>>>           1cba8c0:  0000127b00000009 53434d5600000000  
>>> ....{.......VMCS
>>>           1cba8d0:  000000004f464e49 4e4f495349564552  
>>> INFO....REVISION
>>>           1cba8e0:  49460a643d44495f 5f4e495028444c45  
>>> _ID=d.FIELD(PIN_
>>>           1cba8f0:  4d565f4445534142 4f435f434558455f  
>>> BASED_VM_EXEC_CO
>>>           1cba900:  303d294c4f52544e 0a30383130343831  
>>> NTROL)=01840180.
>>>           1cba910:  504328444c454946 5f44455341425f55  
>>> FIELD(CPU_BASED_
>>>           1cba920:  5f434558455f4d56 294c4f52544e4f43  
>>> VM_EXEC_CONTROL)
>>>           1cba930:  393130343931303d 28444c4549460a30  
>>> =01940190.FIELD(
>>>           1cba940:  5241444e4f434553 4558455f4d565f59  
>>> SECONDARY_VM_EXE
>>>           1cba950:  4f52544e4f435f43 30346566303d294c  
>>> C_CONTROL)=0fe40
>>>           1cba960:  4c4549460a306566 4958455f4d562844  
>>> fe0.FIELD(VM_EXI
>>>           1cba970:  4f52544e4f435f54 346531303d29534c  
>>> T_CONTROLS)=01e4
>>>           1cba980:  4549460a30653130 4e455f4d5628444c  
>>> 01e0.FIELD(VM_EN
>>>           1cba990:  544e4f435f595254 33303d29534c4f52  
>>> TRY_CONTROLS)=03
>>>           1cba9a0:  460a303133303431 45554728444c4549  
>>> 140310.FIELD(GUE
>>>           1cba9b0:  45535f53455f5453 3d29524f5443454c  
>>> ST_ES_SELECTOR)=
>>>           1cba9c0:  4549460a30303530 545345554728444c  
>>> 0500.FIELD(GUEST
>>>           1cba9d0:  454c45535f53435f 35303d29524f5443  
>>> _CS_SELECTOR)=05
>>>           ......
>>>
>>> TODO:
>>>    1. In kexec-tools, get VMCSINFO via sysfs and dump it as note
>>> information
>>>       into vmcore.
>>>    2. Dump VMCS region of each guest vcpu and VMCSINFO into
>>> qemu-process
>>>       core file. To do this, we will modify kernel core dumper, gdb
>>> gcore
>>>       and crash gcore.
>>>    3. Dump guest image from the qemu-process core file into a vmcore.
>>>
>>
>> Taking a step back, can you describe the problem scenario you're fixing
>> here?
>
> Note that assuming that VMCS fields map to offsets within memory is
> not guaranteed to work for future processors.
>
> There is no guarantee that fields won't be compressed or stored with
> inverted bit ordering.
>

Right; they're also not required to be in memory at all - the processor
can cache them, even for VMCSs that are not active at this time. 
Running VMXOFF at panic time can fix that, but you have to broadcast it
to all processors, probably using NMI...

Still, some information is better than nothing.  What I doubt is whether
that information will ever be used.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/17/2012 07:49 PM, Anthony Liguori wrote:
> On 04/17/2012 02:44 AM, Avi Kivity wrote:
>> On 04/11/2012 04:39 AM, zhangyanfei wrote:
>>> This patch set exports offsets of VMCS fields as note information for
>>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>>> runtime state of guest machine image, such as registers, in host
>>> machine's crash dump as VMCS format. The problem is that VMCS
>>> internal is hidden by Intel in its specification. So, we reverse
>>> engineering it in the way implemented in this patch set. Please note
>>> that this processing never affects any existing kvm logic. The
>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>
>>> Here is an example:
>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>
>>> $cat /sys/kernel/vmcsinfo
>>> 1cba8c0 2000
>>>
>>> crash>  rd -p 1cba8c0 1000
>>>           1cba8c0:  0000127b00000009 53434d5600000000  
>>> ....{.......VMCS
>>>           1cba8d0:  000000004f464e49 4e4f495349564552  
>>> INFO....REVISION
>>>           1cba8e0:  49460a643d44495f 5f4e495028444c45  
>>> _ID=d.FIELD(PIN_
>>>           1cba8f0:  4d565f4445534142 4f435f434558455f  
>>> BASED_VM_EXEC_CO
>>>           1cba900:  303d294c4f52544e 0a30383130343831  
>>> NTROL)=01840180.
>>>           1cba910:  504328444c454946 5f44455341425f55  
>>> FIELD(CPU_BASED_
>>>           1cba920:  5f434558455f4d56 294c4f52544e4f43  
>>> VM_EXEC_CONTROL)
>>>           1cba930:  393130343931303d 28444c4549460a30  
>>> =01940190.FIELD(
>>>           1cba940:  5241444e4f434553 4558455f4d565f59  
>>> SECONDARY_VM_EXE
>>>           1cba950:  4f52544e4f435f43 30346566303d294c  
>>> C_CONTROL)=0fe40
>>>           1cba960:  4c4549460a306566 4958455f4d562844  
>>> fe0.FIELD(VM_EXI
>>>           1cba970:  4f52544e4f435f54 346531303d29534c  
>>> T_CONTROLS)=01e4
>>>           1cba980:  4549460a30653130 4e455f4d5628444c  
>>> 01e0.FIELD(VM_EN
>>>           1cba990:  544e4f435f595254 33303d29534c4f52  
>>> TRY_CONTROLS)=03
>>>           1cba9a0:  460a303133303431 45554728444c4549  
>>> 140310.FIELD(GUE
>>>           1cba9b0:  45535f53455f5453 3d29524f5443454c  
>>> ST_ES_SELECTOR)=
>>>           1cba9c0:  4549460a30303530 545345554728444c  
>>> 0500.FIELD(GUEST
>>>           1cba9d0:  454c45535f53435f 35303d29524f5443  
>>> _CS_SELECTOR)=05
>>>           ......
>>>
>>> TODO:
>>>    1. In kexec-tools, get VMCSINFO via sysfs and dump it as note
>>> information
>>>       into vmcore.
>>>    2. Dump VMCS region of each guest vcpu and VMCSINFO into
>>> qemu-process
>>>       core file. To do this, we will modify kernel core dumper, gdb
>>> gcore
>>>       and crash gcore.
>>>    3. Dump guest image from the qemu-process core file into a vmcore.
>>>
>>
>> Taking a step back, can you describe the problem scenario you're fixing
>> here?
>
> Note that assuming that VMCS fields map to offsets within memory is
> not guaranteed to work for future processors.
>
> There is no guarantee that fields won't be compressed or stored with
> inverted bit ordering.
>

Right; they're also not required to be in memory at all - the processor
can cache them, even for VMCSs that are not active at this time. 
Running VMXOFF at panic time can fix that, but you have to broadcast it
to all processors, probably using NMI...

Still, some information is better than nothing.  What I doubt is whether
that information will ever be used.

-- 
error compiling committee.c: too many arguments to function


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

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

[Nadav Har'El]

On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump":
> Right; they're also not required to be in memory at all - the processor
> can cache them, even for VMCSs that are not active at this time. 
> Running VMXOFF at panic time can fix that, but you have to broadcast it
> to all processors, probably using NMI...

I believe that a VMCLEAR ensures that the VMCS is written back to
memory. KVM uses this fact when migrating a VMCS between two separate
physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to
memory, and then VMPTRLD on the new CPU.

So you don't need to VMXOFF, but do need to VMCLEAR. But there's still
the complication that you mention - you need to do the VMCLEAR on the right
processor...


-- 
Nadav Har'El                        |                 Wednesday, Apr 18 2012, 
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |The only "intuitive" interface is the
http://nadav.harel.org.il           |nipple. After that, it's all learned.

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

[Nadav Har'El]

On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump":
> Right; they're also not required to be in memory at all - the processor
> can cache them, even for VMCSs that are not active at this time. 
> Running VMXOFF at panic time can fix that, but you have to broadcast it
> to all processors, probably using NMI...

I believe that a VMCLEAR ensures that the VMCS is written back to
memory. KVM uses this fact when migrating a VMCS between two separate
physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to
memory, and then VMPTRLD on the new CPU.

So you don't need to VMXOFF, but do need to VMCLEAR. But there's still
the complication that you mention - you need to do the VMCLEAR on the right
processor...


-- 
Nadav Har'El                        |                 Wednesday, Apr 18 2012, 
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |The only "intuitive" interface is the
http://nadav.harel.org.il           |nipple. After that, it's all learned.

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

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

[Avi Kivity]

On 04/18/2012 04:47 PM, Nadav Har'El wrote:
> On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump":
> > Right; they're also not required to be in memory at all - the processor
> > can cache them, even for VMCSs that are not active at this time. 
> > Running VMXOFF at panic time can fix that, but you have to broadcast it
> > to all processors, probably using NMI...
>
> I believe that a VMCLEAR ensures that the VMCS is written back to
> memory. KVM uses this fact when migrating a VMCS between two separate
> physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to
> memory, and then VMPTRLD on the new CPU.
>
> So you don't need to VMXOFF, but do need to VMCLEAR. But there's still
> the complication that you mention - you need to do the VMCLEAR on the right
> processor...

VMCLEAR only clears one VMCS; several may be cached by a processor at
one time.  Presumably VMXOFF flushes everything.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/18/2012 04:47 PM, Nadav Har'El wrote:
> On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump":
> > Right; they're also not required to be in memory at all - the processor
> > can cache them, even for VMCSs that are not active at this time. 
> > Running VMXOFF at panic time can fix that, but you have to broadcast it
> > to all processors, probably using NMI...
>
> I believe that a VMCLEAR ensures that the VMCS is written back to
> memory. KVM uses this fact when migrating a VMCS between two separate
> physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to
> memory, and then VMPTRLD on the new CPU.
>
> So you don't need to VMXOFF, but do need to VMCLEAR. But there's still
> the complication that you mention - you need to do the VMCLEAR on the right
> processor...

VMCLEAR only clears one VMCS; several may be cached by a processor at
one time.  Presumably VMXOFF flushes everything.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/18/2012 04:47 PM, Nadav Har'El wrote:
> On Wed, Apr 18, 2012, Avi Kivity wrote about "Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump":
> > Right; they're also not required to be in memory at all - the processor
> > can cache them, even for VMCSs that are not active at this time. 
> > Running VMXOFF at panic time can fix that, but you have to broadcast it
> > to all processors, probably using NMI...
>
> I believe that a VMCLEAR ensures that the VMCS is written back to
> memory. KVM uses this fact when migrating a VMCS between two separate
> physical CPUs - it runs VMCLEAR on the old CPU, to write the VMCS to
> memory, and then VMPTRLD on the new CPU.
>
> So you don't need to VMXOFF, but do need to VMCLEAR. But there's still
> the complication that you mention - you need to do the VMCLEAR on the right
> processor...

VMCLEAR only clears one VMCS; several may be cached by a processor at
one time.  Presumably VMXOFF flushes everything.

-- 
error compiling committee.c: too many arguments to function


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

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Wed, 18 Apr 2012 14:56:39 +0300

> On 04/18/2012 12:49 PM, zhangyanfei wrote:
>> >>
>> > 
>> > What type of resource?  Can you give an example?
>> > 
>> Sorry. No concrete example for now.
>>
>> We are developing this on a conservative policy and I have put the vmcs processing
>> in a new module in patch set v2 as you required. The new module is auto-loaded when
>> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
>> this module will have no side effect on the running guests.
>>
>> And one thing I have to stress is that, we can see guest image as crash dump from
>> guest machine's view if we have the vmcsinfo, this itself is useful.
> 
> Why is it useful?  Without a concrete example, it's hard to justify the
> code bloat.
> 

The reason why we want to retrieve guest machine's memory image as
crash dump is that then we can debug guest machine's status using
symbolic debugger such as gdb and crash utility.

This is very useful. Please consider the situation where engineers are
forced to look into guest machine's memory image through qemu-kvm's
process core dump using gdb without any symbolic information. It's
very inefficient.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Wed, 18 Apr 2012 14:56:39 +0300

> On 04/18/2012 12:49 PM, zhangyanfei wrote:
>> >>
>> > 
>> > What type of resource?  Can you give an example?
>> > 
>> Sorry. No concrete example for now.
>>
>> We are developing this on a conservative policy and I have put the vmcs processing
>> in a new module in patch set v2 as you required. The new module is auto-loaded when
>> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
>> this module will have no side effect on the running guests.
>>
>> And one thing I have to stress is that, we can see guest image as crash dump from
>> guest machine's view if we have the vmcsinfo, this itself is useful.
> 
> Why is it useful?  Without a concrete example, it's hard to justify the
> code bloat.
> 

The reason why we want to retrieve guest machine's memory image as
crash dump is that then we can debug guest machine's status using
symbolic debugger such as gdb and crash utility.

This is very useful. Please consider the situation where engineers are
forced to look into guest machine's memory image through qemu-kvm's
process core dump using gdb without any symbolic information. It's
very inefficient.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Wed, 18 Apr 2012 14:56:39 +0300

> On 04/18/2012 12:49 PM, zhangyanfei wrote:
>> >>
>> > 
>> > What type of resource?  Can you give an example?
>> > 
>> Sorry. No concrete example for now.
>>
>> We are developing this on a conservative policy and I have put the vmcs processing
>> in a new module in patch set v2 as you required. The new module is auto-loaded when
>> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
>> this module will have no side effect on the running guests.
>>
>> And one thing I have to stress is that, we can see guest image as crash dump from
>> guest machine's view if we have the vmcsinfo, this itself is useful.
> 
> Why is it useful?  Without a concrete example, it's hard to justify the
> code bloat.
> 

The reason why we want to retrieve guest machine's memory image as
crash dump is that then we can debug guest machine's status using
symbolic debugger such as gdb and crash utility.

This is very useful. Please consider the situation where engineers are
forced to look into guest machine's memory image through qemu-kvm's
process core dump using gdb without any symbolic information. It's
very inefficient.

Thanks.
HATAYAMA, Daisuke


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

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

[Avi Kivity]

On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote:
> From: Avi Kivity <avi@redhat.com>
> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> Date: Wed, 18 Apr 2012 14:56:39 +0300
>
> > On 04/18/2012 12:49 PM, zhangyanfei wrote:
> >> >>
> >> > 
> >> > What type of resource?  Can you give an example?
> >> > 
> >> Sorry. No concrete example for now.
> >>
> >> We are developing this on a conservative policy and I have put the vmcs processing
> >> in a new module in patch set v2 as you required. The new module is auto-loaded when
> >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
> >> this module will have no side effect on the running guests.
> >>
> >> And one thing I have to stress is that, we can see guest image as crash dump from
> >> guest machine's view if we have the vmcsinfo, this itself is useful.
> > 
> > Why is it useful?  Without a concrete example, it's hard to justify the
> > code bloat.
> > 
>
> The reason why we want to retrieve guest machine's memory image as
> crash dump is that then we can debug guest machine's status using
> symbolic debugger such as gdb and crash utility.
>
> This is very useful. Please consider the situation where engineers are
> forced to look into guest machine's memory image through qemu-kvm's
> process core dump using gdb without any symbolic information. It's
> very inefficient.

I still don't follow.  If qemu crashed, the values in guest registers
are irrelevant.  In what way can the help debug the qemu crash?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote:
> From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> Date: Wed, 18 Apr 2012 14:56:39 +0300
>
> > On 04/18/2012 12:49 PM, zhangyanfei wrote:
> >> >>
> >> > 
> >> > What type of resource?  Can you give an example?
> >> > 
> >> Sorry. No concrete example for now.
> >>
> >> We are developing this on a conservative policy and I have put the vmcs processing
> >> in a new module in patch set v2 as you required. The new module is auto-loaded when
> >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
> >> this module will have no side effect on the running guests.
> >>
> >> And one thing I have to stress is that, we can see guest image as crash dump from
> >> guest machine's view if we have the vmcsinfo, this itself is useful.
> > 
> > Why is it useful?  Without a concrete example, it's hard to justify the
> > code bloat.
> > 
>
> The reason why we want to retrieve guest machine's memory image as
> crash dump is that then we can debug guest machine's status using
> symbolic debugger such as gdb and crash utility.
>
> This is very useful. Please consider the situation where engineers are
> forced to look into guest machine's memory image through qemu-kvm's
> process core dump using gdb without any symbolic information. It's
> very inefficient.

I still don't follow.  If qemu crashed, the values in guest registers
are irrelevant.  In what way can the help debug the qemu crash?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote:
> From: Avi Kivity <avi@redhat.com>
> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> Date: Wed, 18 Apr 2012 14:56:39 +0300
>
> > On 04/18/2012 12:49 PM, zhangyanfei wrote:
> >> >>
> >> > 
> >> > What type of resource?  Can you give an example?
> >> > 
> >> Sorry. No concrete example for now.
> >>
> >> We are developing this on a conservative policy and I have put the vmcs processing
> >> in a new module in patch set v2 as you required. The new module is auto-loaded when
> >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
> >> this module will have no side effect on the running guests.
> >>
> >> And one thing I have to stress is that, we can see guest image as crash dump from
> >> guest machine's view if we have the vmcsinfo, this itself is useful.
> > 
> > Why is it useful?  Without a concrete example, it's hard to justify the
> > code bloat.
> > 
>
> The reason why we want to retrieve guest machine's memory image as
> crash dump is that then we can debug guest machine's status using
> symbolic debugger such as gdb and crash utility.
>
> This is very useful. Please consider the situation where engineers are
> forced to look into guest machine's memory image through qemu-kvm's
> process core dump using gdb without any symbolic information. It's
> very inefficient.

I still don't follow.  If qemu crashed, the values in guest registers
are irrelevant.  In what way can the help debug the qemu crash?

-- 
error compiling committee.c: too many arguments to function


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

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 13:42:42 +0300

> On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote:
>> From: Avi Kivity <avi@redhat.com>
>> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
>> Date: Wed, 18 Apr 2012 14:56:39 +0300
>>
>> > On 04/18/2012 12:49 PM, zhangyanfei wrote:
>> >> >>
>> >> > 
>> >> > What type of resource?  Can you give an example?
>> >> > 
>> >> Sorry. No concrete example for now.
>> >>
>> >> We are developing this on a conservative policy and I have put the vmcs processing
>> >> in a new module in patch set v2 as you required. The new module is auto-loaded when
>> >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
>> >> this module will have no side effect on the running guests.
>> >>
>> >> And one thing I have to stress is that, we can see guest image as crash dump from
>> >> guest machine's view if we have the vmcsinfo, this itself is useful.
>> > 
>> > Why is it useful?  Without a concrete example, it's hard to justify the
>> > code bloat.
>> > 
>>
>> The reason why we want to retrieve guest machine's memory image as
>> crash dump is that then we can debug guest machine's status using
>> symbolic debugger such as gdb and crash utility.
>>
>> This is very useful. Please consider the situation where engineers are
>> forced to look into guest machine's memory image through qemu-kvm's
>> process core dump using gdb without any symbolic information. It's
>> very inefficient.
> 
> I still don't follow.  If qemu crashed, the values in guest registers
> are irrelevant.  In what way can the help debug the qemu crash?
> 

It would be not helpful for the qemu crash case you are concerned
about. We want to use the guest state data to look into guest
machine's image in the crasshed qemu.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 13:42:42 +0300

> On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote:
>> From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
>> Date: Wed, 18 Apr 2012 14:56:39 +0300
>>
>> > On 04/18/2012 12:49 PM, zhangyanfei wrote:
>> >> >>
>> >> > 
>> >> > What type of resource?  Can you give an example?
>> >> > 
>> >> Sorry. No concrete example for now.
>> >>
>> >> We are developing this on a conservative policy and I have put the vmcs processing
>> >> in a new module in patch set v2 as you required. The new module is auto-loaded when
>> >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
>> >> this module will have no side effect on the running guests.
>> >>
>> >> And one thing I have to stress is that, we can see guest image as crash dump from
>> >> guest machine's view if we have the vmcsinfo, this itself is useful.
>> > 
>> > Why is it useful?  Without a concrete example, it's hard to justify the
>> > code bloat.
>> > 
>>
>> The reason why we want to retrieve guest machine's memory image as
>> crash dump is that then we can debug guest machine's status using
>> symbolic debugger such as gdb and crash utility.
>>
>> This is very useful. Please consider the situation where engineers are
>> forced to look into guest machine's memory image through qemu-kvm's
>> process core dump using gdb without any symbolic information. It's
>> very inefficient.
> 
> I still don't follow.  If qemu crashed, the values in guest registers
> are irrelevant.  In what way can the help debug the qemu crash?
> 

It would be not helpful for the qemu crash case you are concerned
about. We want to use the guest state data to look into guest
machine's image in the crasshed qemu.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 13:42:42 +0300

> On 04/19/2012 01:36 PM, HATAYAMA Daisuke wrote:
>> From: Avi Kivity <avi@redhat.com>
>> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
>> Date: Wed, 18 Apr 2012 14:56:39 +0300
>>
>> > On 04/18/2012 12:49 PM, zhangyanfei wrote:
>> >> >>
>> >> > 
>> >> > What type of resource?  Can you give an example?
>> >> > 
>> >> Sorry. No concrete example for now.
>> >>
>> >> We are developing this on a conservative policy and I have put the vmcs processing
>> >> in a new module in patch set v2 as you required. The new module is auto-loaded when
>> >> the vmx cpufeature is detected and it depends on module kvm-intel. Loading and unloading
>> >> this module will have no side effect on the running guests.
>> >>
>> >> And one thing I have to stress is that, we can see guest image as crash dump from
>> >> guest machine's view if we have the vmcsinfo, this itself is useful.
>> > 
>> > Why is it useful?  Without a concrete example, it's hard to justify the
>> > code bloat.
>> > 
>>
>> The reason why we want to retrieve guest machine's memory image as
>> crash dump is that then we can debug guest machine's status using
>> symbolic debugger such as gdb and crash utility.
>>
>> This is very useful. Please consider the situation where engineers are
>> forced to look into guest machine's memory image through qemu-kvm's
>> process core dump using gdb without any symbolic information. It's
>> very inefficient.
> 
> I still don't follow.  If qemu crashed, the values in guest registers
> are irrelevant.  In what way can the help debug the qemu crash?
> 

It would be not helpful for the qemu crash case you are concerned
about. We want to use the guest state data to look into guest
machine's image in the crasshed qemu.

Thanks.
HATAYAMA, Daisuke


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

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

[Avi Kivity]

On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote:
> >> The reason why we want to retrieve guest machine's memory image as
> >> crash dump is that then we can debug guest machine's status using
> >> symbolic debugger such as gdb and crash utility.
> >>
> >> This is very useful. Please consider the situation where engineers are
> >> forced to look into guest machine's memory image through qemu-kvm's
> >> process core dump using gdb without any symbolic information. It's
> >> very inefficient.
> > 
> > I still don't follow.  If qemu crashed, the values in guest registers
> > are irrelevant.  In what way can the help debug the qemu crash?
> > 
>
> It would be not helpful for the qemu crash case you are concerned
> about. We want to use the guest state data to look into guest
> machine's image in the crasshed qemu.

Why?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote:
> >> The reason why we want to retrieve guest machine's memory image as
> >> crash dump is that then we can debug guest machine's status using
> >> symbolic debugger such as gdb and crash utility.
> >>
> >> This is very useful. Please consider the situation where engineers are
> >> forced to look into guest machine's memory image through qemu-kvm's
> >> process core dump using gdb without any symbolic information. It's
> >> very inefficient.
> > 
> > I still don't follow.  If qemu crashed, the values in guest registers
> > are irrelevant.  In what way can the help debug the qemu crash?
> > 
>
> It would be not helpful for the qemu crash case you are concerned
> about. We want to use the guest state data to look into guest
> machine's image in the crasshed qemu.

Why?

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote:
> >> The reason why we want to retrieve guest machine's memory image as
> >> crash dump is that then we can debug guest machine's status using
> >> symbolic debugger such as gdb and crash utility.
> >>
> >> This is very useful. Please consider the situation where engineers are
> >> forced to look into guest machine's memory image through qemu-kvm's
> >> process core dump using gdb without any symbolic information. It's
> >> very inefficient.
> > 
> > I still don't follow.  If qemu crashed, the values in guest registers
> > are irrelevant.  In what way can the help debug the qemu crash?
> > 
>
> It would be not helpful for the qemu crash case you are concerned
> about. We want to use the guest state data to look into guest
> machine's image in the crasshed qemu.

Why?

-- 
error compiling committee.c: too many arguments to function


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

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 14:31:56 +0300

> On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote:
>> >> The reason why we want to retrieve guest machine's memory image as
>> >> crash dump is that then we can debug guest machine's status using
>> >> symbolic debugger such as gdb and crash utility.
>> >>
>> >> This is very useful. Please consider the situation where engineers are
>> >> forced to look into guest machine's memory image through qemu-kvm's
>> >> process core dump using gdb without any symbolic information. It's
>> >> very inefficient.
>> > 
>> > I still don't follow.  If qemu crashed, the values in guest registers
>> > are irrelevant.  In what way can the help debug the qemu crash?
>> > 
>>
>> It would be not helpful for the qemu crash case you are concerned
>> about. We want to use the guest state data to look into guest
>> machine's image in the crasshed qemu.
> 
> Why?
> 

It seems natural to check the situation from guest machine's side when
qemu crashs. Suppose a service is running on the guest machine, and
then the qemu crash. Then, we may need to know the details of the
progress of the service if it's important. What has been successfully
done, and what has not yet.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 14:31:56 +0300

> On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote:
>> >> The reason why we want to retrieve guest machine's memory image as
>> >> crash dump is that then we can debug guest machine's status using
>> >> symbolic debugger such as gdb and crash utility.
>> >>
>> >> This is very useful. Please consider the situation where engineers are
>> >> forced to look into guest machine's memory image through qemu-kvm's
>> >> process core dump using gdb without any symbolic information. It's
>> >> very inefficient.
>> > 
>> > I still don't follow.  If qemu crashed, the values in guest registers
>> > are irrelevant.  In what way can the help debug the qemu crash?
>> > 
>>
>> It would be not helpful for the qemu crash case you are concerned
>> about. We want to use the guest state data to look into guest
>> machine's image in the crasshed qemu.
> 
> Why?
> 

It seems natural to check the situation from guest machine's side when
qemu crashs. Suppose a service is running on the guest machine, and
then the qemu crash. Then, we may need to know the details of the
progress of the service if it's important. What has been successfully
done, and what has not yet.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 14:31:56 +0300

> On 04/19/2012 02:27 PM, HATAYAMA Daisuke wrote:
>> >> The reason why we want to retrieve guest machine's memory image as
>> >> crash dump is that then we can debug guest machine's status using
>> >> symbolic debugger such as gdb and crash utility.
>> >>
>> >> This is very useful. Please consider the situation where engineers are
>> >> forced to look into guest machine's memory image through qemu-kvm's
>> >> process core dump using gdb without any symbolic information. It's
>> >> very inefficient.
>> > 
>> > I still don't follow.  If qemu crashed, the values in guest registers
>> > are irrelevant.  In what way can the help debug the qemu crash?
>> > 
>>
>> It would be not helpful for the qemu crash case you are concerned
>> about. We want to use the guest state data to look into guest
>> machine's image in the crasshed qemu.
> 
> Why?
> 

It seems natural to check the situation from guest machine's side when
qemu crashs. Suppose a service is running on the guest machine, and
then the qemu crash. Then, we may need to know the details of the
progress of the service if it's important. What has been successfully
done, and what has not yet.

Thanks.
HATAYAMA, Daisuke


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

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

[Avi Kivity]

On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> >> It would be not helpful for the qemu crash case you are concerned
> >> about. We want to use the guest state data to look into guest
> >> machine's image in the crasshed qemu.
> > 
> > Why?
> > 
>
> It seems natural to check the situation from guest machine's side when
> qemu crashs. Suppose a service is running on the guest machine, and
> then the qemu crash. Then, we may need to know the details of the
> progress of the service if it's important. What has been successfully
> done, and what has not yet.

How can a service on the guest be related to a qemu crash?  And how
would guest registers help?

You can extract the list of running processes from a qemu crash dump
without looking at guest registers.  And most vcpus are running
asynchronously to qemu, so their register contents is irrelevant (if a
vcpu is running synchronously with qemu - it just exited to qemu and is
waiting for a response - then you'd see the details in qemu's call stack).

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> >> It would be not helpful for the qemu crash case you are concerned
> >> about. We want to use the guest state data to look into guest
> >> machine's image in the crasshed qemu.
> > 
> > Why?
> > 
>
> It seems natural to check the situation from guest machine's side when
> qemu crashs. Suppose a service is running on the guest machine, and
> then the qemu crash. Then, we may need to know the details of the
> progress of the service if it's important. What has been successfully
> done, and what has not yet.

How can a service on the guest be related to a qemu crash?  And how
would guest registers help?

You can extract the list of running processes from a qemu crash dump
without looking at guest registers.  And most vcpus are running
asynchronously to qemu, so their register contents is irrelevant (if a
vcpu is running synchronously with qemu - it just exited to qemu and is
waiting for a response - then you'd see the details in qemu's call stack).

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> >> It would be not helpful for the qemu crash case you are concerned
> >> about. We want to use the guest state data to look into guest
> >> machine's image in the crasshed qemu.
> > 
> > Why?
> > 
>
> It seems natural to check the situation from guest machine's side when
> qemu crashs. Suppose a service is running on the guest machine, and
> then the qemu crash. Then, we may need to know the details of the
> progress of the service if it's important. What has been successfully
> done, and what has not yet.

How can a service on the guest be related to a qemu crash?  And how
would guest registers help?

You can extract the list of running processes from a qemu crash dump
without looking at guest registers.  And most vcpus are running
asynchronously to qemu, so their register contents is irrelevant (if a
vcpu is running synchronously with qemu - it just exited to qemu and is
waiting for a response - then you'd see the details in qemu's call stack).

-- 
error compiling committee.c: too many arguments to function


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

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 15:08:00 +0300

> On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
>> >> It would be not helpful for the qemu crash case you are concerned
>> >> about. We want to use the guest state data to look into guest
>> >> machine's image in the crasshed qemu.
>> > 
>> > Why?
>> > 
>>
>> It seems natural to check the situation from guest machine's side when
>> qemu crashs. Suppose a service is running on the guest machine, and
>> then the qemu crash. Then, we may need to know the details of the
>> progress of the service if it's important. What has been successfully
>> done, and what has not yet.
> 
> How can a service on the guest be related to a qemu crash?  And how
> would guest registers help?

I don't mean the service is related to qemu's crash. When qemu
crashes, then the guest machine also crashes (although it doesn't
notice anything). What I'm interested in here is guest machine side,
not qemu side. I want to debug guest machine, not qemu.

> 
> You can extract the list of running processes from a qemu crash dump
> without looking at guest registers.  And most vcpus are running
> asynchronously to qemu, so their register contents is irrelevant (if a
> vcpu is running synchronously with qemu - it just exited to qemu and is
> waiting for a response - then you'd see the details in qemu's call stack).
> 

Just as you say, we can refer to guest machine's memory without guest
registers.

The definitely necessary data in vmcs are RSP and RIP, which are not
saved in anywhare of kvm module. The two registers are needed for back
tracing to determine what processsing is being done on the guest
machine at qemu crash.

There are other useful data in vmcs, but even if we don't have them,
we can do what we want to do in exchange of usability.

For example, we want IA32_EFER.LMA to determine whether guest machine
is in 32-bit or 64-bit mode. But there are only two modes, we can
perhaps try these in order in an ad-hoc way.

Other control registers are also useful, but they are not so important
than definitely needed.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 15:08:00 +0300

> On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
>> >> It would be not helpful for the qemu crash case you are concerned
>> >> about. We want to use the guest state data to look into guest
>> >> machine's image in the crasshed qemu.
>> > 
>> > Why?
>> > 
>>
>> It seems natural to check the situation from guest machine's side when
>> qemu crashs. Suppose a service is running on the guest machine, and
>> then the qemu crash. Then, we may need to know the details of the
>> progress of the service if it's important. What has been successfully
>> done, and what has not yet.
> 
> How can a service on the guest be related to a qemu crash?  And how
> would guest registers help?

I don't mean the service is related to qemu's crash. When qemu
crashes, then the guest machine also crashes (although it doesn't
notice anything). What I'm interested in here is guest machine side,
not qemu side. I want to debug guest machine, not qemu.

> 
> You can extract the list of running processes from a qemu crash dump
> without looking at guest registers.  And most vcpus are running
> asynchronously to qemu, so their register contents is irrelevant (if a
> vcpu is running synchronously with qemu - it just exited to qemu and is
> waiting for a response - then you'd see the details in qemu's call stack).
> 

Just as you say, we can refer to guest machine's memory without guest
registers.

The definitely necessary data in vmcs are RSP and RIP, which are not
saved in anywhare of kvm module. The two registers are needed for back
tracing to determine what processsing is being done on the guest
machine at qemu crash.

There are other useful data in vmcs, but even if we don't have them,
we can do what we want to do in exchange of usability.

For example, we want IA32_EFER.LMA to determine whether guest machine
is in 32-bit or 64-bit mode. But there are only two modes, we can
perhaps try these in order in an ad-hoc way.

Other control registers are also useful, but they are not so important
than definitely needed.

Thanks.
HATAYAMA, Daisuke

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

[HATAYAMA Daisuke]

From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
Date: Thu, 19 Apr 2012 15:08:00 +0300

> On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
>> >> It would be not helpful for the qemu crash case you are concerned
>> >> about. We want to use the guest state data to look into guest
>> >> machine's image in the crasshed qemu.
>> > 
>> > Why?
>> > 
>>
>> It seems natural to check the situation from guest machine's side when
>> qemu crashs. Suppose a service is running on the guest machine, and
>> then the qemu crash. Then, we may need to know the details of the
>> progress of the service if it's important. What has been successfully
>> done, and what has not yet.
> 
> How can a service on the guest be related to a qemu crash?  And how
> would guest registers help?

I don't mean the service is related to qemu's crash. When qemu
crashes, then the guest machine also crashes (although it doesn't
notice anything). What I'm interested in here is guest machine side,
not qemu side. I want to debug guest machine, not qemu.

> 
> You can extract the list of running processes from a qemu crash dump
> without looking at guest registers.  And most vcpus are running
> asynchronously to qemu, so their register contents is irrelevant (if a
> vcpu is running synchronously with qemu - it just exited to qemu and is
> waiting for a response - then you'd see the details in qemu's call stack).
> 

Just as you say, we can refer to guest machine's memory without guest
registers.

The definitely necessary data in vmcs are RSP and RIP, which are not
saved in anywhare of kvm module. The two registers are needed for back
tracing to determine what processsing is being done on the guest
machine at qemu crash.

There are other useful data in vmcs, but even if we don't have them,
we can do what we want to do in exchange of usability.

For example, we want IA32_EFER.LMA to determine whether guest machine
is in 32-bit or 64-bit mode. But there are only two modes, we can
perhaps try these in order in an ad-hoc way.

Other control registers are also useful, but they are not so important
than definitely needed.

Thanks.
HATAYAMA, Daisuke


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

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

[Avi Kivity]

On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote:
> From: Avi Kivity <avi@redhat.com>
> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> Date: Thu, 19 Apr 2012 15:08:00 +0300
>
> > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> >> >> It would be not helpful for the qemu crash case you are concerned
> >> >> about. We want to use the guest state data to look into guest
> >> >> machine's image in the crasshed qemu.
> >> > 
> >> > Why?
> >> > 
> >>
> >> It seems natural to check the situation from guest machine's side when
> >> qemu crashs. Suppose a service is running on the guest machine, and
> >> then the qemu crash. Then, we may need to know the details of the
> >> progress of the service if it's important. What has been successfully
> >> done, and what has not yet.
> > 
> > How can a service on the guest be related to a qemu crash?  And how
> > would guest registers help?
>
> I don't mean the service is related to qemu's crash. When qemu
> crashes, then the guest machine also crashes (although it doesn't
> notice anything). What I'm interested in here is guest machine side,
> not qemu side. I want to debug guest machine, not qemu.

There is no bug in the guest, so why debug it?

It's similar to pulling out the power from a server and wanting to
inspect the registers and memory at the time the cpu died.  Even if it's
possible, you don't gain any information from it.

> > 
> > You can extract the list of running processes from a qemu crash dump
> > without looking at guest registers.  And most vcpus are running
> > asynchronously to qemu, so their register contents is irrelevant (if a
> > vcpu is running synchronously with qemu - it just exited to qemu and is
> > waiting for a response - then you'd see the details in qemu's call stack).
> > 
>
> Just as you say, we can refer to guest machine's memory without guest
> registers.
>
> The definitely necessary data in vmcs are RSP and RIP, which are not
> saved in anywhare of kvm module. The two registers are needed for back
> tracing to determine what processsing is being done on the guest
> machine at qemu crash.

What I don't understand is why you are interested in the guest machine
at all, if it was qemu that crashed.

> There are other useful data in vmcs, but even if we don't have them,
> we can do what we want to do in exchange of usability.
>
> For example, we want IA32_EFER.LMA to determine whether guest machine
> is in 32-bit or 64-bit mode. But there are only two modes, we can
> perhaps try these in order in an ad-hoc way.
>
> Other control registers are also useful, but they are not so important
> than definitely needed.
>

If this is your interest, then the data should be encoded in a vendor
agnostic way.  That is, not as lists of vmcs fields, but instead guest
registers.  This can be implemented for both vmx and svm.

However this is secondary to the question of why we need to do this at all.

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote:
> From: Avi Kivity <avi@redhat.com>
> Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> Date: Thu, 19 Apr 2012 15:08:00 +0300
>
> > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> >> >> It would be not helpful for the qemu crash case you are concerned
> >> >> about. We want to use the guest state data to look into guest
> >> >> machine's image in the crasshed qemu.
> >> > 
> >> > Why?
> >> > 
> >>
> >> It seems natural to check the situation from guest machine's side when
> >> qemu crashs. Suppose a service is running on the guest machine, and
> >> then the qemu crash. Then, we may need to know the details of the
> >> progress of the service if it's important. What has been successfully
> >> done, and what has not yet.
> > 
> > How can a service on the guest be related to a qemu crash?  And how
> > would guest registers help?
>
> I don't mean the service is related to qemu's crash. When qemu
> crashes, then the guest machine also crashes (although it doesn't
> notice anything). What I'm interested in here is guest machine side,
> not qemu side. I want to debug guest machine, not qemu.

There is no bug in the guest, so why debug it?

It's similar to pulling out the power from a server and wanting to
inspect the registers and memory at the time the cpu died.  Even if it's
possible, you don't gain any information from it.

> > 
> > You can extract the list of running processes from a qemu crash dump
> > without looking at guest registers.  And most vcpus are running
> > asynchronously to qemu, so their register contents is irrelevant (if a
> > vcpu is running synchronously with qemu - it just exited to qemu and is
> > waiting for a response - then you'd see the details in qemu's call stack).
> > 
>
> Just as you say, we can refer to guest machine's memory without guest
> registers.
>
> The definitely necessary data in vmcs are RSP and RIP, which are not
> saved in anywhare of kvm module. The two registers are needed for back
> tracing to determine what processsing is being done on the guest
> machine at qemu crash.

What I don't understand is why you are interested in the guest machine
at all, if it was qemu that crashed.

> There are other useful data in vmcs, but even if we don't have them,
> we can do what we want to do in exchange of usability.
>
> For example, we want IA32_EFER.LMA to determine whether guest machine
> is in 32-bit or 64-bit mode. But there are only two modes, we can
> perhaps try these in order in an ad-hoc way.
>
> Other control registers are also useful, but they are not so important
> than definitely needed.
>

If this is your interest, then the data should be encoded in a vendor
agnostic way.  That is, not as lists of vmcs fields, but instead guest
registers.  This can be implemented for both vmx and svm.

However this is secondary to the question of why we need to do this at all.

-- 
error compiling committee.c: too many arguments to function


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

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

[Gleb Natapov]

On Sun, Apr 22, 2012 at 12:58:35PM +0300, Avi Kivity wrote:
> On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote:
> > From: Avi Kivity <avi@redhat.com>
> > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> > Date: Thu, 19 Apr 2012 15:08:00 +0300
> >
> > > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> > >> >> It would be not helpful for the qemu crash case you are concerned
> > >> >> about. We want to use the guest state data to look into guest
> > >> >> machine's image in the crasshed qemu.
> > >> > 
> > >> > Why?
> > >> > 
> > >>
> > >> It seems natural to check the situation from guest machine's side when
> > >> qemu crashs. Suppose a service is running on the guest machine, and
> > >> then the qemu crash. Then, we may need to know the details of the
> > >> progress of the service if it's important. What has been successfully
> > >> done, and what has not yet.
> > > 
> > > How can a service on the guest be related to a qemu crash?  And how
> > > would guest registers help?
> >
> > I don't mean the service is related to qemu's crash. When qemu
> > crashes, then the guest machine also crashes (although it doesn't
> > notice anything). What I'm interested in here is guest machine side,
> > not qemu side. I want to debug guest machine, not qemu.
> 
> There is no bug in the guest, so why debug it?
> 
> It's similar to pulling out the power from a server and wanting to
> inspect the registers and memory at the time the cpu died.  Even if it's
> possible, you don't gain any information from it.
> 
> > > 
> > > You can extract the list of running processes from a qemu crash dump
> > > without looking at guest registers.  And most vcpus are running
> > > asynchronously to qemu, so their register contents is irrelevant (if a
> > > vcpu is running synchronously with qemu - it just exited to qemu and is
> > > waiting for a response - then you'd see the details in qemu's call stack).
> > > 
> >
> > Just as you say, we can refer to guest machine's memory without guest
> > registers.
> >
> > The definitely necessary data in vmcs are RSP and RIP, which are not
> > saved in anywhare of kvm module. The two registers are needed for back
> > tracing to determine what processsing is being done on the guest
> > machine at qemu crash.
> 
> What I don't understand is why you are interested in the guest machine
> at all, if it was qemu that crashed.
> 
It would be interesting to extract enough information from the core to be
able to restart the guest from the point where qemu crashed, but
decoding VMCS is not enough for that.

--
			Gleb.

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

[Gleb Natapov]

On Sun, Apr 22, 2012 at 12:58:35PM +0300, Avi Kivity wrote:
> On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote:
> > From: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> > Date: Thu, 19 Apr 2012 15:08:00 +0300
> >
> > > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> > >> >> It would be not helpful for the qemu crash case you are concerned
> > >> >> about. We want to use the guest state data to look into guest
> > >> >> machine's image in the crasshed qemu.
> > >> > 
> > >> > Why?
> > >> > 
> > >>
> > >> It seems natural to check the situation from guest machine's side when
> > >> qemu crashs. Suppose a service is running on the guest machine, and
> > >> then the qemu crash. Then, we may need to know the details of the
> > >> progress of the service if it's important. What has been successfully
> > >> done, and what has not yet.
> > > 
> > > How can a service on the guest be related to a qemu crash?  And how
> > > would guest registers help?
> >
> > I don't mean the service is related to qemu's crash. When qemu
> > crashes, then the guest machine also crashes (although it doesn't
> > notice anything). What I'm interested in here is guest machine side,
> > not qemu side. I want to debug guest machine, not qemu.
> 
> There is no bug in the guest, so why debug it?
> 
> It's similar to pulling out the power from a server and wanting to
> inspect the registers and memory at the time the cpu died.  Even if it's
> possible, you don't gain any information from it.
> 
> > > 
> > > You can extract the list of running processes from a qemu crash dump
> > > without looking at guest registers.  And most vcpus are running
> > > asynchronously to qemu, so their register contents is irrelevant (if a
> > > vcpu is running synchronously with qemu - it just exited to qemu and is
> > > waiting for a response - then you'd see the details in qemu's call stack).
> > > 
> >
> > Just as you say, we can refer to guest machine's memory without guest
> > registers.
> >
> > The definitely necessary data in vmcs are RSP and RIP, which are not
> > saved in anywhare of kvm module. The two registers are needed for back
> > tracing to determine what processsing is being done on the guest
> > machine at qemu crash.
> 
> What I don't understand is why you are interested in the guest machine
> at all, if it was qemu that crashed.
> 
It would be interesting to extract enough information from the core to be
able to restart the guest from the point where qemu crashed, but
decoding VMCS is not enough for that.

--
			Gleb.

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

[Gleb Natapov]

On Sun, Apr 22, 2012 at 12:58:35PM +0300, Avi Kivity wrote:
> On 04/20/2012 01:11 PM, HATAYAMA Daisuke wrote:
> > From: Avi Kivity <avi@redhat.com>
> > Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump
> > Date: Thu, 19 Apr 2012 15:08:00 +0300
> >
> > > On 04/19/2012 03:01 PM, HATAYAMA Daisuke wrote:
> > >> >> It would be not helpful for the qemu crash case you are concerned
> > >> >> about. We want to use the guest state data to look into guest
> > >> >> machine's image in the crasshed qemu.
> > >> > 
> > >> > Why?
> > >> > 
> > >>
> > >> It seems natural to check the situation from guest machine's side when
> > >> qemu crashs. Suppose a service is running on the guest machine, and
> > >> then the qemu crash. Then, we may need to know the details of the
> > >> progress of the service if it's important. What has been successfully
> > >> done, and what has not yet.
> > > 
> > > How can a service on the guest be related to a qemu crash?  And how
> > > would guest registers help?
> >
> > I don't mean the service is related to qemu's crash. When qemu
> > crashes, then the guest machine also crashes (although it doesn't
> > notice anything). What I'm interested in here is guest machine side,
> > not qemu side. I want to debug guest machine, not qemu.
> 
> There is no bug in the guest, so why debug it?
> 
> It's similar to pulling out the power from a server and wanting to
> inspect the registers and memory at the time the cpu died.  Even if it's
> possible, you don't gain any information from it.
> 
> > > 
> > > You can extract the list of running processes from a qemu crash dump
> > > without looking at guest registers.  And most vcpus are running
> > > asynchronously to qemu, so their register contents is irrelevant (if a
> > > vcpu is running synchronously with qemu - it just exited to qemu and is
> > > waiting for a response - then you'd see the details in qemu's call stack).
> > > 
> >
> > Just as you say, we can refer to guest machine's memory without guest
> > registers.
> >
> > The definitely necessary data in vmcs are RSP and RIP, which are not
> > saved in anywhare of kvm module. The two registers are needed for back
> > tracing to determine what processsing is being done on the guest
> > machine at qemu crash.
> 
> What I don't understand is why you are interested in the guest machine
> at all, if it was qemu that crashed.
> 
It would be interesting to extract enough information from the core to be
able to restart the guest from the point where qemu crashed, but
decoding VMCS is not enough for that.

--
			Gleb.

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

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

[Avi Kivity]

On 04/22/2012 01:33 PM, Gleb Natapov wrote:
> > 
> > What I don't understand is why you are interested in the guest machine
> > at all, if it was qemu that crashed.
> > 
> It would be interesting to extract enough information from the core to be
> able to restart the guest from the point where qemu crashed, but
> decoding VMCS is not enough for that.

Interesting idea.  It should be possible if you attach all kvm state to
the core (and do quite a lot of digging to recover device model state).

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/22/2012 01:33 PM, Gleb Natapov wrote:
> > 
> > What I don't understand is why you are interested in the guest machine
> > at all, if it was qemu that crashed.
> > 
> It would be interesting to extract enough information from the core to be
> able to restart the guest from the point where qemu crashed, but
> decoding VMCS is not enough for that.

Interesting idea.  It should be possible if you attach all kvm state to
the core (and do quite a lot of digging to recover device model state).

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 04/22/2012 01:33 PM, Gleb Natapov wrote:
> > 
> > What I don't understand is why you are interested in the guest machine
> > at all, if it was qemu that crashed.
> > 
> It would be interesting to extract enough information from the core to be
> able to restart the guest from the point where qemu crashed, but
> decoding VMCS is not enough for that.

Interesting idea.  It should be possible if you attach all kvm state to
the core (and do quite a lot of digging to recover device model state).

-- 
error compiling committee.c: too many arguments to function


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