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.

freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to