rumpkernel and bhyve: triple faults

[Peter Grehan]

Hi Fabian,

>> For a page-fault, the virtual address that resulted in the fault
>> will
be in the CR2 register.
> 
> I don’t 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’m pretty sure it’s tooling that’s displaying something off, since
>hopper is showing me this as
> 
> 0x0000000000102a56         cmp        word [0x2], 0x0
> 
> Which is very similar to what r2 is giving me:
> 
> ;-- 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 
why this would generate a page-fault - the zero page is often mapped 
read-only. Perhaps rumpkernel doesn't have a mapping for it, but then, 
the offset for the access would be incorrect (maybe a linking issue with 
the location of variables ?).

> Maybe I’m off with my analysis of the actual fault here, but how I understand
> the source (assuming compilers work as I would expect, which is not always true)
> the values here are initialised from values in the bios data area (which is
> zeroed out on bhyve):

  It shouldn't matter that those were zero. Loading them into a memory 
location shouldn't be a problem.

> Here’s my full output from bhyvectl --get-all:
> 
> 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 
that rumpkernel has set up it's own mappings, since the multiboot loader 
entered the guest in flat 32-bit mode.

> cr0[0]          0x0000000080010031

  Paging is enabled (bit 31) as expected.

later,

PEter.