[coreboot] [Fwd: Re: [Qemu-devel] Release plan for 0.12.0]
c-d.hailfinger.devel.2006 at gmx.net
Sat Oct 3 00:31:38 CEST 2009
Comments? Please try to add the original recipients to CC if you answer.
-------- Original Message --------
Subject: Re: [Qemu-devel] Release plan for 0.12.0
Date: Fri, 02 Oct 2009 16:37:49 -0500
From: Anthony Liguori <aliguori at us.ibm.com>
To: Jordan Justen <jljusten at gmail.com>
CC: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>,
qemu-devel at nongnu.org
References: <4AC29E4D.80707 at us.ibm.com>
<D0452B81-706B-4154-92E1-6E253A305053 at claunia.com>
<4AC4A487.1050003 at us.ibm.com>
<2a50f7880910011410u6afbb658hf99839fdb3e7bab1 at mail.gmail.com>
<4AC51DBA.7020609 at codemonkey.ws>
<2a50f7880910011741k65ac8dfbq2fc8c9f58f5fa8d9 at mail.gmail.com>
<4AC60037.6000001 at codemonkey.ws>
<2a50f7880910020958g3fe5eadehe5e5094c05b218d9 at mail.gmail.com>
<4AC64A5C.6010003 at gmx.net>
<2a50f7880910021357i2b441f5flb98b1fa41c5f2150 at mail.gmail.com>
Jordan Justen wrote:
> 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.
More information about the coreboot