Skip site navigation (1)Skip section navigation (2)
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=20
> particular, I'd like to take a whack at improving the PCI INTx =
support, but=20
> that can involve several things such as possibly implementing 8259A =
support=20
> and a PCI interrupt router vs always assuming that we have APICs.  If =
we do=20
> want to support a more legacy route, is there interest in supporting a =
BIOS=20
> interface in the VM?  I know that one option is to go grab a BIOS ROM =
from=20
> something like qemu, but another option is to have the real-mode IDT =
vector to=20
> stub routines in a very small ROM that traps to the hypervisor to =
implement=20
> BIOS requests.  OTOH, that may turn out to be rather messy.
>=20
> Finally, I noticed a comment fly by about removing the need for =
bhyveload. =20
> One thing I have found useful recently is passing -H to bhyveload. =20
> Specifically, I can build a test kernel outside of the VM on the host =
and=20
> access it via the host0 filesystem in bhyveload so I can easily test =
kernels=20
> in the VM while still using the host as my development environment.  =
It would=20
> be nice to retain this ability in some fashion.
>=20
> --=20
> 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>