> 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)
Well in that case my original claim that there
is not a legacy isa vga device avaliable would
be correct for this environment, and you should
just eliminate anything that tries to use it,
or make it understand that this device may not
exist. I am not sure if bhyve maps any of these
legacy addresses if your not using bhyveloader
or uefi bios code. 0x400 and 0x483 being
unmapped could lead to your tripple fault.
> 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: 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.
> freebsd-virtualizat...@freebsd.org mailing list
> To unsubscribe, send any mail to
Rod Grimes rgri...@freebsd.org