Date: Wed, 22 Jan 2014 19:54:47 -0500 From: Tycho Nightingale <tycho.nightingale@pluribusnetworks.com> To: John Baldwin <jhb@freebsd.org> Cc: virtualization@freebsd.org Subject: Re: bhyve and legacy Message-ID: <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com> In-Reply-To: <201401221715.42164.jhb@freebsd.org> References: <201401221715.42164.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. Tycho On Jan 22, 2014, at 5:15 PM, John Baldwin <jhb@freebsd.org> wrote: > Is there any interest in supporting more "legacy" setups via bhyve? In > particular, I'd like to take a whack at improving the PCI INTx support, but > that can involve several things such as possibly implementing 8259A support > and a PCI interrupt router vs always assuming that we have APICs. If we do > want to support a more legacy route, is there interest in supporting a BIOS > interface in the VM? I know that one option is to go grab a BIOS ROM from > something like qemu, but another option is to have the real-mode IDT vector to > stub routines in a very small ROM that traps to the hypervisor to implement > BIOS requests. OTOH, that may turn out to be rather messy. > > Finally, I noticed a comment fly by about removing the need for bhyveload. > One thing I have found useful recently is passing -H to bhyveload. > Specifically, I can build a test kernel outside of the VM on the host and > access it via the host0 filesystem in bhyveload so I can easily test kernels > in the VM while still using the host as my development environment. It would > be nice to retain this ability in some fashion. > > -- > John Baldwin > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22CF9C41-3320-4E98-A475-A6372799024B>