> Hello lists,
>
> I?m currently playing around with getting rump kernels built with
> rumpkernel(7) running on FreeBSD?s bhyve(4). I?m using a custom boot loader
> [1] which builds on some patches to bhyveload / user boot [2].
>
> To test, I?m using a simple ?helloer? unikernel from the tutori
> > Hello lists,
> >
> > I?m currently playing around with getting rump kernels built with
> > rumpkernel(7) running on FreeBSD?s bhyve(4). I?m using a custom boot loader
> > [1] which builds on some patches to bhyveload / user boot [2].
> >
> > To test, I?m using a simple ?helloer? unikernel f
On 6 Mar 2018, at 9:28, Rodney W. Grimes wrote:
bios_crtc_base would be part of the isa legacy vga
controller card. Bhyve does not, at this time, or
in the near future expect to have, support for this
legacy device.
I am wrong on this, the framebuffer device does
infact have support for the l
> On 6 Mar 2018, at 9:28, Rodney W. Grimes wrote:
>
> >> bios_crtc_base would be part of the isa legacy vga
> >> controller card. Bhyve does not, at this time, or
> >> in the near future expect to have, support for this
> >> legacy device.
> >
> > I am wrong on this, the framebuffer device does
>
(un-CC’ing rumpkernel-users@, since this part of the
discussion is getting very bhyve-specific)
On 6 Mar 2018, at 10:18, Rodney W. Grimes wrote:
On 6 Mar 2018, at 9:28, Rodney W. Grimes wrote:
bios_crtc_base would be part of the isa legacy vga
controller card. Bhyve does not, at this time, o
Hi Fabian,
657 0 350887309700 vm testing[0]: handled exception vmexit at 0x102a56
656 0 350887309570 vm testing[0]: Exception 14 pending
655 0 350887309442 vm testing[0]: Setting intr_shadow to 0 succeeded
654 0 350887305126 vm testing[0]: Reflecting excep
Hi Peter,
On 6 Mar 2018, at 16:15, Peter Grehan wrote:
> Exception 14 is a page fault (SDM Vol3 ch 6.15). The exception type is
> "fault" which means it is delivered at the address it was detected at.
>
> This cascaded very quickly into a triple-fault, so it looks like it could
> possibly be a
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
