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.
