From owner-freebsd-virtualization@freebsd.org Tue Mar 6 15:15:49 2018 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7D93F39C57 for ; Tue, 6 Mar 2018 15:15:49 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from vito.onthenet.com.au (vito.onthenet.com.au [203.22.124.72]) by mx1.freebsd.org (Postfix) with ESMTP id 088FE7B33A for ; Tue, 6 Mar 2018 15:15:48 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by vito.onthenet.com.au (Postfix) with ESMTP id 86A712076FB0 for ; Wed, 7 Mar 2018 01:15:46 +1000 (AEST) Received: from iredmail.onthenet.com.au (iredmail.onthenet.com.au [203.13.68.150]) by alto.onthenet.com.au (Postfix) with ESMTPS id 6819C20B4A0C for ; Wed, 7 Mar 2018 01:15:46 +1000 (AEST) Received: from localhost (iredmail.onthenet.com.au [127.0.0.1]) by iredmail.onthenet.com.au (Postfix) with ESMTP id 5C210281A4B for ; Wed, 7 Mar 2018 01:15:46 +1000 (AEST) X-Amavis-Modified: Mail body modified (using disclaimer) - iredmail.onthenet.com.au Received: from iredmail.onthenet.com.au ([127.0.0.1]) by localhost (iredmail.onthenet.com.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qtSbALU1VroP for ; Wed, 7 Mar 2018 01:15:46 +1000 (AEST) Received: from Peters-MacBook-Pro-2.local (c-67-180-92-13.hsd1.ca.comcast.net [67.180.92.13]) by iredmail.onthenet.com.au (Postfix) with ESMTPSA id 6482F2804D6; Wed, 7 Mar 2018 01:15:43 +1000 (AEST) Subject: Re: rumpkernel and bhyve: triple faults To: Fabian Freyer References: From: Peter Grehan Cc: freebsd-virtualization@freebsd.org, rumpkernel-users@freelists.org Message-ID: <651856d3-3c34-9930-cda1-62d41091f91f@freebsd.org> Date: Tue, 6 Mar 2018 07:15:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=dNCIZtRb c=1 sm=1 tr=0 a=A6CF0fG5TOl4vs6YHvqXgw==:117 a=5eVCmCvhg37cu/pjidAGzw==:17 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=BRlsKWOS0KQfm44lbqQA:9 a=y3tL4Oqu7xm67Kjg:21 a=9dlVhwN69FE26nys:21 a=QEXdDO2ut3YA:10 wl=host:3 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=Mvd8FVSe c=1 sm=1 tr=0 a=mJOSnoNX3k71adV6TmU0eQ==:117 a=5eVCmCvhg37cu/pjidAGzw==:17 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=BRlsKWOS0KQfm44lbqQA:9 a=y3tL4Oqu7xm67Kjg:21 a=9dlVhwN69FE26nys:21 a=QEXdDO2ut3YA:10 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 15:15:50 -0000 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='. 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 : > 102a50: push rbx > 102a51: call 103540 > 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). later, Peter.