> 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 tutorial [3]:
> 
... excelent discription of your debug process removed for breif reply ...

> Due to compiler optimisations, the check here isn?t the
> (hypervisor == HYPERVISOR_XEN) check directly after the call to 
> hypervisor_detect,
> but the check (bios_crtc_base == 0) in

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.


> 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?


> I?m not sure where to go from here. Is this a bug in bhyve(4),
No, it is not a bug, it is an unimplemented device.

> should these
> values be initialised somehow, or should I patch rumpkernel(7) to skip this 
> check
> when running on bhyve(4)?
rumpkernel is assuming or requiring the presence of legacy isa hardware,
it should probably be taught that this may not exist.  You could simply
skip this check, but I expect you would then have a harder to find
failure later when it tries to use the hardware it expects to be
there.

> 
> Fabian
 
... Full KTR trace removed for breif reply ...


-- 
Rod Grimes                                                 rgri...@freebsd.org

Reply via email to