Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

Hi Jordan,

I have to admit that I'm not the expert for coreboot+EFI solutions. I
know they exist and work, but I'll defer to other developers on the
coreboot list to give you detailed answers. Please see below for what I
think I know (but I'll gladly accept any corrections).


On 02.10.2009 22:57, 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?
>   

This mail is CC: to the coreboot list and I'm sure someone who knows
more than I can respond.

The documentation about Tianocore/UEFI/EFI is not entirely clear about
the names of each part of the stack, but if I understand correctly,
there is a hardware init part (OVMF for Qemu) and parts which boot EFI
enabled operating systems, provide EFI services to the operating system,
or give users a shell to work from.

coreboot is pure hardware init (CPU, RAM, chipset, PCI), it has no
drivers whatsoever. It does provide ACPI tables for the hardware and a
memory map. Once coreboot finishes hardware initialization, it passes
control to a payload (which has drivers, boots the OS, provides
services). That payload is hardware-independent unless it explicitly
wants to contain non-generic drivers. It is possible to use the exact
same SeaBIOS binary as coreboot payload on Qemu, Pentium III systems
with i440BX chipset, AMD Phenom systems with 690G chipset, Via Nano
systems with VX800 chipset, and Intel Core 2 Duo systems with i945 chipset.
Unless I'm mistaken, OVMF and coreboot have pretty much the same purpose.


> 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.
>   

Please don't get me wrong. The number of developers in the open source
firmware space is small and I'm happy that you're such a developer. My
main worry is splitting one task among too many projects, with the
danger of frustation if only one project is accepted into Qemu. I don't
have an axe to grind against EFI (which is desired by many people) or
OVMF (which is purpose-built for UEFI in Qemu).
That's why I want to understand your goals and hope to find a way to
accomplish your goals, coreboot goals and at the same time have Qemu get
the best firmware possible.


> Thanks,
>
> -Jordan
>   

Regards,
Carl-Daniel

> On Fri, Oct 2, 2009 at 11:45, Carl-Daniel Hailfinger
> <address@hidden> wrote:
>   
>> On 02.10.2009 18:58, Jordan Justen wrote:
>>     
>>> On Fri, Oct 2, 2009 at 06:29, Anthony Liguori <address@hidden> 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
>>