Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen <jljusten@gmail.com>]

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.

Thanks,

-Jordan

On Fri, Oct 2, 2009 at 11:45, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
> On 02.10.2009 18:58, Jordan Justen wrote:
>> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>
>>> So I think the best way forward is to hold off on UEFI in mainline until we
>>> can provide a single unified stack.
>>>
>>
>> While it is true that a separate machine type could potentially be
>> viewed as increasing the testing requirements, I am not so sure.  If
>> QEMU has a UEFI+CSM solution, wouldn't we still have to test both UEFI
>> based OS boot and the CSM based legacy OS boot?
>>
>
> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and
> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI
> interface), wouldn't that solve all problems in one go? You get an
> unified stack and don't have to mess around with different firmware
> files because coreboot can read in a Qemu machine config option (or
> NVRAM/CMOS) and select the interface based on that.
>
> The hardware init part would be identical for all variants, only the
> interface would differ. coreboot works now and has the benefit of
> supporting real hardware as well, so the difference between a setup
> inside Qemu and a setup on real hardware is minimal.
>
>
>>>> I don't know of any efforts to create an open source CSM.  Is someone
>>>> working on converting SeaBIOS to act as a CSM?
>>>>
>
> The coreboot solution would also avoid converting SeaBIOS because
> SeaBIOS already works as coreboot payload (that's how coreboot
> developers call the CSM).
>
>
>> I do know that we don't intend to start an open source CSM project on
>> tianocore.org at this time.
>>
>> But, if such a project was started, I think we would support
>> development via email on our edk2 dev list, and potentially even host
>> the project on tianocore.org.
>>
>> So, I would invite anyone thinking of tackling such a task to join the
>> edk2 dev list to discuss your work.  Furthermore, if you'd like to
>> request the project to be hosted on tianocore.org, feel free to ask
>> our administrators.  (As mentioned previously, we usually deal with
>> the BSD license on tianocore.org, but please don't let this hold you
>> back from asking questions, or requesting hosting of your project.)
>>
>
> I do invite everyone who is interested in having one single ROM file
> with EFI+SeaBIOS to join the coreboot list as well. We already have
> coreboot+SeaBIOS running (both on hardware and inside Qemu) and
> coreboot+tianocore works as well. It has the advantage of requiring zero
> changes in coreboot, zero changes in SeaBIOS and (I think) zero changes
> in Tianocore.
>
> As a nice side benefit for the EFI specialists, you get the ability to
> run EFI on every coreboot supported platform.
>
>
> If you have any questions, please ask.
>
> Regards,
> Carl-Daniel
>