Hi Fabian,

For a page-fault, the virtual address that resulted in the fault
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.



Reply via email to