Date: Thu, 23 Jan 2014 14:58:23 -0500 From: John Baldwin <jhb@freebsd.org> To: Tycho Nightingale <tycho.nightingale@pluribusnetworks.com> Cc: virtualization@freebsd.org Subject: Re: bhyve and legacy Message-ID: <201401231458.23719.jhb@freebsd.org> In-Reply-To: <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com> References: <201401221715.42164.jhb@freebsd.org> <22CF9C41-3320-4E98-A475-A6372799024B@pluribusnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201401231458.23719.jhb>