Hi Fabian,

    657   0     350887309700 vm testing[0]: handled exception vmexit at 0x102a56
    656   0     350887309570 vm testing[0]: Exception 14 pending
    655   0     350887309442 vm testing[0]: Setting intr_shadow to 0 succeeded
    654   0     350887305126 vm testing[0]: Reflecting exception 14/0 into the 
    653   0     350887302436 vm testing[0]: vm_exit_intinfo: info1(0x80000b0e)
    652   0     350887248280 vm testing[0]: Resume execution at 0x102a56
    651   0     350887184160 vm testing[0]: vm_entry_intinfo: info1(0), 
info2(0x80000b0e), retinfo(0x80000b0e)
    650   0     350887184040 vm testing[0]: Exception 14 delivered: 0x80000b0e
    649   0     350887182668 vm testing[0]: 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 name>'.

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 <current_lwp+0x2>

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).


freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to