From owner-freebsd-virtualization@freebsd.org Tue Mar 6 09:18:17 2018 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D995CF4306B for ; Tue, 6 Mar 2018 09:18:16 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48FF86C4F2 for ; Tue, 6 Mar 2018 09:18:15 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w269ICbw048091; Tue, 6 Mar 2018 01:18:12 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w269IAl1048090; Tue, 6 Mar 2018 01:18:10 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803060918.w269IAl1048090@pdx.rh.CN85.dnsmgr.net> Subject: Re: rumpkernel and bhyve: triple faults In-Reply-To: <256A0D22-46D6-44DA-9ACF-631FE981D0EC@physik.tu-berlin.de> To: Fabian Freyer Date: Tue, 6 Mar 2018 01:18:10 -0800 (PST) CC: rumpkernel-users@freelists.org, freebsd-virtualization@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 09:18:17 -0000 > 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