linux-kernel - [PATCH] x86, add hypervisor name to dump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1351259807-13739-1-git-send-email-prarit@redhat.com>
Date:	Fri, 26 Oct 2012 09:56:47 -0400
From:	Prarit Bhargava <prarit@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	Prarit Bhargava <prarit@...hat.com>, Avi Kivity <avi@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	Marcelo Tostatti <mtosatti@...hat.com>,
	Ingo Molnar <mingo@...hat.com>, kvm@...r.kernel.org,
	x86@...nel.org
Subject: [PATCH] x86, add hypervisor name to dump_stack() [v2]

Debugging crash, panics, stack trace WARN_ONs, etc., from both virtual and
bare-metal boots can get difficult very quickly.  While there are ways to
decipher the output and determine if the output is from a virtual guest,
the in-kernel hypervisors now have a single registration point
and set x86_hyper.  We can use this to output additional debug
information during a panic/oops/stack trace.

Signed-off-by: Prarit Bhargava <prarit@...hat.com>
Cc: Avi Kivity <avi@...hat.com>
Cc: Gleb Natapov <gleb@...hat.com>
Cc: Alex Williamson <alex.williamson@...hat.com>
Cc: Marcelo Tostatti <mtosatti@...hat.com>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: kvm@...r.kernel.org
Cc: x86@...nel.org

[v2]: Modifications suggested by Ingo and added changes for similar output
      from process.c
---
 arch/x86/kernel/dumpstack.c |   11 ++++++++++-
 arch/x86/kernel/process.c   |   12 +++++++++++-
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index ae42418b..5dd680f 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -16,6 +16,7 @@
 #include <linux/nmi.h>
 #include <linux/sysfs.h>
 
+#include <asm/hypervisor.h>
 #include <asm/stacktrace.h>
 
 
@@ -186,9 +187,17 @@ void dump_stack(void)
 {
 	unsigned long bp;
 	unsigned long stack;
+	const char *machine_name = "x86";
+	const char *kernel_type = "native";
+
+	if (x86_hyper) {
+		machine_name = x86_hyper->name;
+		kernel_type = "guest";
+	}
 
 	bp = stack_frame(current, NULL);
-	printk("Pid: %d, comm: %.20s %s %s %.*s\n",
+	printk("[%s %s kernel] Pid: %d, comm: %.20s %s %s %.*s\n",
+		machine_name, kernel_type,
 		current->pid, current->comm, print_tainted(),
 		init_utsname()->release,
 		(int)strcspn(init_utsname()->version, " "),
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index b644e1c..14bd064 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include <asm/fpu-internal.h>
 #include <asm/debugreg.h>
 #include <asm/nmi.h>
+#include <asm/hypervisor.h>
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -124,6 +125,13 @@ void exit_thread(void)
 void show_regs_common(void)
 {
 	const char *vendor, *product, *board;
+	const char *machine_name = "x86";
+	const char *kernel_type = "native";
+
+	if (x86_hyper) {
+		machine_name = x86_hyper->name;
+		kernel_type = "guest";
+	}
 
 	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
 	if (!vendor)
@@ -135,7 +143,9 @@ void show_regs_common(void)
 	/* Board Name is optional */
 	board = dmi_get_system_info(DMI_BOARD_NAME);
 
-	printk(KERN_DEFAULT "Pid: %d, comm: %.20s %s %s %.*s %s %s%s%s\n",
+	printk(KERN_DEFAULT
+	       "[%s %s kernel] Pid: %d, comm: %.20s %s %s %.*s %s %s%s%s\n",
+	       machine_name, kernel_type,
 	       current->pid, current->comm, print_tainted(),
 	       init_utsname()->release,
 	       (int)strcspn(init_utsname()->version, " "),
-- 
1.7.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/