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
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
