657 0 350887309700 vm testing: handled exception vmexit at 0x102a56
656 0 350887309570 vm testing: Exception 14 pending
655 0 350887309442 vm testing: Setting intr_shadow to 0 succeeded
654 0 350887305126 vm testing: Reflecting exception 14/0 into the
653 0 350887302436 vm testing: vm_exit_intinfo: info1(0x80000b0e)
652 0 350887248280 vm testing: Resume execution at 0x102a56
651 0 350887184160 vm testing: vm_entry_intinfo: info1(0),
650 0 350887184040 vm testing: Exception 14 delivered: 0x80000b0e
649 0 350887182668 vm testing: handled exception vmexit at 0x102a56
Exception 14 is a page fault (SDM Vol3 ch 6.15). The exception type is
"fault" which means it is delivered at the address it was detected at.
This cascaded very quickly into a triple-fault, so it looks like it
could possibly be an issue with the stack. One debug tool you do have is
to get a register dump on exit, with 'bhyvectl --get-all --vm=<your vn
For a page-fault, the virtual address that resulted in the fault will
be in the CR2 register.
From the code at the faulting address:
> 0000000000102a50 <cons_init>:
> 102a50: push rbx
> 102a51: call 103540 <hypervisor_detect>
> 102a56: cmp WORD PTR [rip-0x102a5c],0x0 # 2
It's using RIP-relative addressing here, but objdump seems to think
this may be an offset in the current_lwp structure - is it possible that
may have an uninitialized value ?
(I don't believe this has anything to do with VGA).
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to