On Thu, Oct 23, 2014 at 6:55 PM, Peter Grehan <gre...@freebsd.org> wrote: >> Also, flip Bhyve /domain/os/type support from HVM to Xen. Bhyve only >> supports paravirtualized guests, and 'xen' is closest to that. > > That's not true: bhyve has enough h/w emulation required to run unmodified > guests - there are register-level emulations of the local APIC, I/O APIC, > PIT, PIC, RTC, HPET, APCI timer, PCI/PCIe support, and AHCI. > > While virtio devices may be categorised as PV, in reality they're seen by a > guest o/s as PCI devices and can be considered HVM. > > The bhyveload/grub-bhyve user-space loaders are an artifact of how bhyve > was initially developed - they will be made redundant when the UEFI work is > done, at which point bhyve will have a BIOS.
Hi Peter, I'm happy to drop the hvm -> xen changes. I'll need to change the domain parsing code to allow hvm domains to set <bootloader> options — currently it only allows xen domains to do so. Unless I'm mistaken, the userspace loaders are still needed to boot VMs for now. Will the Bhyve UEFI work be complete before MeetBSD? And is it going into the FreeBSD 10 release branch, or only in 11? Until that code actually materializes, I think it's important to fix libvirt now. This change doesn't break a future Bhyve-that-supports EUFI, and it can even be yanked out later if totally redundant. Until UEFI support materializes, Linux guests are broken in libvirt-bhyve. I'll rework and submit a v2. Thanks, Conrad _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"