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:
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
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.
Paging is enabled (bit 31) as expected.