Date: Tue, 6 Mar 2018 19:03:24 -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: <1f1161ee-4543-6802-59a5-290e6c8c0329@freebsd.org> In-Reply-To: <2AAD4069-7D37-4325-8990-21C5DFD80B3B@physik.tu-berlin.de> References: <C49D0E56-10A4-49D8-A843-E371395831B5@physik.tu-berlin.de> <651856d3-3c34-9930-cda1-62d41091f91f@freebsd.org> <2AAD4069-7D37-4325-8990-21C5DFD80B3B@physik.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1f1161ee-4543-6802-59a5-290e6c8c0329>