From owner-freebsd-virtualization@freebsd.org Wed Mar 7 03:03:34 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 7D954F4804D for ; Wed, 7 Mar 2018 03:03:34 +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 C248C795AF for ; Wed, 7 Mar 2018 03:03:33 +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 6A6B12095C5E for ; Wed, 7 Mar 2018 13:03:31 +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 519D920B1AE1 for ; Wed, 7 Mar 2018 13:03:31 +1000 (AEST) Received: from localhost (iredmail.onthenet.com.au [127.0.0.1]) by iredmail.onthenet.com.au (Postfix) with ESMTP id 4BCAA281A4B for ; Wed, 7 Mar 2018 13:03:31 +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 80kxVTW9g82y for ; Wed, 7 Mar 2018 13:03:31 +1000 (AEST) Received: from Peters-MacBook-Pro-2.local (96-82-80-65-static.hfc.comcastbusiness.net [96.82.80.65]) by iredmail.onthenet.com.au (Postfix) with ESMTPSA id 6C776280A18; Wed, 7 Mar 2018 13:03:28 +1000 (AEST) Subject: Re: rumpkernel and bhyve: triple faults To: Fabian Freyer Cc: freebsd-virtualization@freebsd.org, rumpkernel-users@freelists.org References: <651856d3-3c34-9930-cda1-62d41091f91f@freebsd.org> <2AAD4069-7D37-4325-8990-21C5DFD80B3B@physik.tu-berlin.de> From: Peter Grehan Message-ID: <1f1161ee-4543-6802-59a5-290e6c8c0329@freebsd.org> Date: Tue, 6 Mar 2018 19:03:24 -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: <2AAD4069-7D37-4325-8990-21C5DFD80B3B@physik.tu-berlin.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=dNCIZtRb c=1 sm=1 tr=0 a=A6CF0fG5TOl4vs6YHvqXgw==:117 a=mwgbnDbW7alINpy3vhoKyg==:17 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=GcetEkhIoyJB3HI8B2UA:9 a=hRAa9tYipjSx2e2k:21 a=p7G98uB1is8chpi9: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=mwgbnDbW7alINpy3vhoKyg==:17 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=GcetEkhIoyJB3HI8B2UA:9 a=hRAa9tYipjSx2e2k:21 a=p7G98uB1is8chpi9: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: Wed, 07 Mar 2018 03:03:34 -0000 Hi Fabian, >> For a page-fault, the virtual address that resulted in the fault >> will be in the CR2 register. >=20 > I don=E2=80=99t see a CR2 register in the output of bhyvectl --get-all,= I > was looking for that too. Oops, I'll add that to bhyvectl. > I=E2=80=99m pretty sure it=E2=80=99s tooling that=E2=80=99s displaying = something off, since >hopper is showing me this as >=20 > 0x0000000000102a56 cmp word [0x2], 0x0 >=20 > Which is very similar to what r2 is giving me: >=20 > ;-- cons_init: > 0x00102a50 53 push rbx ; /arch/x86:= 43 > 0x00102a51 e8ea0a0000 call sym.hypervisor_detect ; /arch/x86:= 47 > 0x00102a56 66833da4d5ef. cmp word [0x00000002], 0 ; /arch/x86:= 62 This is reading the 16-bit value from memory location 0x2. Hard to see=20 why this would generate a page-fault - the zero page is often mapped=20 read-only. Perhaps rumpkernel doesn't have a mapping for it, but then,=20 the offset for the access would be incorrect (maybe a linking issue with=20 the location of variables ?). > Maybe I=E2=80=99m off with my analysis of the actual fault here, but ho= w I understand > the source (assuming compilers work as I would expect, which is not alw= ays true) > the values here are initialised from values in the bios data area (whic= h is > zeroed out on bhyve): It shouldn't matter that those were zero. Loading them into a memory=20 location shouldn't be a problem. > Here=E2=80=99s my full output from bhyvectl --get-all: >=20 > ID Length Name > 0 128MB sysmem > Address Length Segment Offset Prot Flags > 0 128MB sysmem 0 RWX > efer[0] 0x0000000000000500 Ok, the guest is in 64-bit mode - the LMA bit is set. This implies=20 that rumpkernel has set up it's own mappings, since the multiboot loader=20 entered the guest in flat 32-bit mode. > cr0[0] 0x0000000080010031 Paging is enabled (bit 31) as expected. later, PEter.