Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Mar 2018 07:15:41 -0800
From:      Peter Grehan <grehan@freebsd.org>
To:        Fabian Freyer <fabian.freyer@physik.tu-berlin.de>
Cc:        freebsd-virtualization@freebsd.org, rumpkernel-users@freelists.org
Subject:   Re: rumpkernel and bhyve: triple faults
Message-ID:  <651856d3-3c34-9930-cda1-62d41091f91f@freebsd.org>
In-Reply-To: <C49D0E56-10A4-49D8-A843-E371395831B5@physik.tu-berlin.de>
References:  <C49D0E56-10A4-49D8-A843-E371395831B5@physik.tu-berlin.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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 guest
>     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).

later,

Peter.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?651856d3-3c34-9930-cda1-62d41091f91f>