rumpkernel and bhyve: triple faults

Fabian Freyer fabian.freyer at physik.tu-berlin.de
Tue Mar 6 08:53:25 UTC 2018


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 legacy i/o addresses
> that this should point to.  You should see the
> "vgaconf" section of the FrameBuffer section
> of the bhyve(8) manpage.
>
> I believe you need to be running bhyve with the
> uefi bios options, the with CMS version, and
> have vgaconf=on to get your code to work as is.

For diskless multiboot kernels I’m going with a
separate userboot.so-compatible loader. Specifying
a UEFI bootrom implicitly resets the CPU.
(See usr.sbin/bhyve/bhyverun.c:960)

I think deciding to use the serial output (which is
what most of rumpkernel’s cons_init is doing) based
on the hypervisor is probably the right way to go.
Something similar is already done for XEN:

     /*
      * If running under Xen use the serial console.
      */
     if (hypervisor == HYPERVISOR_XEN)
         prefer_serial = 1;

>>> rumprun/platform/hw/arch/x86/cons.c:59:
>>>    649   0     350887182668 vm testing[0]: handled exception vmexit 
>>> at 0x102a56
>>>
>>> Therefore, I?m assuming this is the origin of the fault.
>>>
>>> Tracking down bios_crtc_base, I find that it?s loaded in
>>> rumprun/platform/hw/arch/amd64/locore.S:70:
>>>
>>> 	/* save BIOS data area values */
>>> 	movw BIOS_COM1_BASE, %bx
>>> 	movw %bx, bios_com1_base
>>> 	movw BIOS_CRTC_BASE, %bx
>>> 	movw %bx, bios_crtc_base
>>>
>>> Where BIOS_CRTC_BASE is 0x463 and BIOS_COM1_BASE is 0x400. Checking 
>>> the bhyve
>>> device node in /dev/vmm with xxd(1), I find the words at these 
>>> addresses to be
>>> Uninitialised:
>>>
>>> 00000400: 0000                                     ..
>>> 00000483: 0000                                     ..
>> Typo here, should this be 00000463?
Yes, sorry about that.

Fabian


More information about the freebsd-virtualization mailing list