From owner-freebsd-virtualization@freebsd.org Tue Mar 6 08:28:40 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 39D1BF3F442 for ; Tue, 6 Mar 2018 08:28:40 +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 A101F6A389 for ; Tue, 6 Mar 2018 08:28:39 +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 w268Sbrm047943; Tue, 6 Mar 2018 00:28:37 -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 w268SbZX047942; Tue, 6 Mar 2018 00:28:37 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803060828.w268SbZX047942@pdx.rh.CN85.dnsmgr.net> Subject: Re: rumpkernel and bhyve: triple faults In-Reply-To: <201803060806.w2686Shu047819@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" Date: Tue, 6 Mar 2018 00:28:37 -0800 (PST) CC: Fabian Freyer , 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 08:28:40 -0000 > > 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. 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. > > 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 rgrimes@freebsd.org