user/vmm: print RIP and hexdump of RIP[0:16] on failed vmexit handling.
authorRonald G. Minnich <rminnich@gmail.com>
Fri, 3 Jun 2016 20:45:32 +0000 (13:45 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Sat, 4 Jun 2016 13:13:17 +0000 (09:13 -0400)
Sometimes the current status dump is not quite enough for debugging.
One example is when the RIP somehow ends up with a weird value,
e.g. the middle of allocated memory, and that code is hence
not visible in the disassembled kernel.

The exit now prints a bit more information, and a hex dump of
the 16 bytes starting at RIP. This little extra bit of information
allowed me to figure out a strange problem I was having.

Change-Id: Ic37396d48bfe8934d7943e9ac6729540468badfa
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
user/vmm/sched.c

index a489f6d..d8973b8 100644 (file)
@@ -322,6 +322,16 @@ static void __ctlr_entry(void)
        struct virtual_machine *vm = gth_to_vm(cth->buddy);
 
        if (!handle_vmexit(cth->buddy)) {
+               struct vm_trapframe *vm_tf = gth_to_vmtf(cth->buddy);
+
+               fprintf(stderr, "vmm: handle_vmexit returned false\n");
+               fprintf(stderr, "Note: this may be a kernel module, not the kernel\n");
+               fprintf(stderr, "RIP was %p:\n", (void *)vm_tf->tf_rip);
+               /* TODO: properly walk the kernel page tables to map the tf_rip
+                * to a physical address. For now, however, this hack is good
+                * enough.
+                */
+               hexdump(stderr, (void *)(vm_tf->tf_rip & 0x3fffffff), 16);
                showstatus(stderr, cth->buddy);
                exit(0);
        }