From owner-freebsd-virtualization@freebsd.org Tue Mar 6 08:53:25 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 4B2C0F4136C for ; Tue, 6 Mar 2018 08:53:25 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from mail.physik.tu-berlin.de (mail.physik-pool.tu-berlin.de [130.149.50.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E24A26B818 for ; Tue, 6 Mar 2018 08:53:24 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from [192.168.119.1] (wlan-141-23-171-244.tubit.tu-berlin.de [141.23.171.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.physik.tu-berlin.de (Postfix) with ESMTPSA id EB56762069; Tue, 6 Mar 2018 08:53:21 +0000 (UTC) From: "Fabian Freyer" To: "Rodney W. Grimes" Cc: rumpkernel-users@freelists.org, freebsd-virtualization@freebsd.org Subject: Re: rumpkernel and bhyve: triple faults Date: Tue, 06 Mar 2018 09:53:21 +0100 X-Mailer: MailMate (1.10r5443) Message-ID: <256A0D22-46D6-44DA-9ACF-631FE981D0EC@physik.tu-berlin.de> In-Reply-To: <201803060828.w268SbZX047942@pdx.rh.CN85.dnsmgr.net> References: <201803060828.w268SbZX047942@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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:53:25 -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) 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