qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Release plan for 0.12.0


From: Anthony Liguori
Subject: Re: [Qemu-devel] Release plan for 0.12.0
Date: Fri, 02 Oct 2009 16:37:49 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Jordan Justen wrote:
Carl-Daniel,

Interesting.  So, where can I download a QEMU bios rom to boot a UEFI
OS with this solution?

Can you explain what coreboot+tianocore means?  Which parts of
tianocore do you use in this situation?

If your solution can accomplish all of what you say, I'm not sure how
OVMF would be able to compete against in terms of being included with
QEMU.  Part of the reason for starting OVMF was to help enable UEFI
support within VM's such as QEMU.  If OVMF was utilized by QEMU it
definitely would have been a bit of a boost for our efforts, but if
QEMU accomplishes UEFI support via another path, then overall we will
still be happy.

FWIW, I looked more closely at Coreboot + SeaBIOS today. It's much less functional than just SeaBIOS alone. There really is no additional functionality because all payloads that Coreboot can run already run directly under QEMU (or under SeaBIOS).

With respect to Coreboot + SeaBIOS + UEFI, AFAIK, you cannot have multiple payloads without using essentially a payload switcher (like Bayou). The problem with this though is your just deferring the EFI/BIOS choice to the user in a different place. What we need is a mechanism to transparently choose UEFI or SeaBIOS depending on whether the guest is EFI aware.

I think option roms further complicate the matter because we would need a gPXE EFI module to support network boot. That makes the switch logic even more complicated. For PCI passthrough, I assume that the legacy option ROMs have to be loaded through a CSM so if we want to enable PCI passthrough, we really need a proper CSM.

--
Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]