Date: Tue, 6 Mar 2018 01:18:10 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Fabian Freyer <fabian.freyer@physik.tu-berlin.de> Cc: rumpkernel-users@freelists.org, freebsd-virtualization@freebsd.org Subject: Re: rumpkernel and bhyve: triple faults Message-ID: <201803060918.w269IAl1048090@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <256A0D22-46D6-44DA-9ACF-631FE981D0EC@physik.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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[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-unsubscribe@freebsd.org" > > -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803060918.w269IAl1048090>