[coreboot] [Fwd: Re: [Qemu-devel] Release plan for 0.12.0]

[Carl-Daniel Hailfinger]

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 
To: 	Jordan Justen 
CC: 	Carl-Daniel Hailfinger ,
[e-mail]
References: 	








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.