From owner-freebsd-virtualization@FreeBSD.ORG Thu Jan 23 20:34:44 2014 Return-Path: Delivered-To: virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9A853B6 for ; Thu, 23 Jan 2014 20:34:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9240217FB for ; Thu, 23 Jan 2014 20:34:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 76CA6B917; Thu, 23 Jan 2014 15:34:43 -0500 (EST) From: John Baldwin To: Tycho Nightingale Subject: Re: bhyve and legacy Date: Thu, 23 Jan 2014 14:58:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401221715.42164.jhb@freebsd.org> <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com> In-Reply-To: <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401231458.23719.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Jan 2014 15:34:43 -0500 (EST) Cc: virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.17 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: Thu, 23 Jan 2014 20:34:44 -0000 On Wednesday, January 22, 2014 7:54:47 pm Tycho Nightingale wrote: > > Hi, > > Interest? Yes! Matter of fact, I have some scraps of 8259 support lying around here if you are keen to have a starting point. I think most of 8259A could live in the hypervisor in userland. I think all that would be needed in vmm.ko would be a way to do the equivalent of asserting ExtInt with a specific IDT vector value and having the VMM code honor the mask bits on lapic LINT0 and the I/O APIC ExtInt pins for deciding when to deliver it to a CPU. > Now with respect to bhyveload, while it certainly does have some FreeBSD- specific uses, it is a bit of a barrier to supporting non-FreeBSD guests and furthermore supporting them well e.g. reboot without bhyve exiting. If 'true' support existed for booting from an iso, then with a quick 'mkisofs' you could achieve the same kernel-to-VM turnaround without bhyveload. Well, not quite as nice, but close. One nice thing about the current host0: approach is I can actually use 'nextboot -e bootfile=foo' inside the VM to trigger a boot of a test kernel similar to using 'nextboot -k foo' on real hardware. That's not quite as easy to arrange in the ISO case given that ISO's generally only show up if you boot from them. What would be interesting perhaps would be a way to PXE boot from the host. That would be a closer approximation to how bhyveload -H works. -- John Baldwin