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