Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

On 03.10.2009 00:28, Jordan Justen wrote:
> On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Jordan, I have to admit that I'm surprised OVMF was apparently created
>> from scratch although quite a few (established) hardware init solutions
>> already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old
>> hobbyist projects.
>>     
>
> The edk2 project provides an infrastructure for building complete UEFI
> firmware solutions.  OVMF is a sample platform which demonstrates how
> edk2 can be used to build firmware to boot a UEFI platform.
>   

I wish to apologize for the misunderstanding. I thought OVMF was only
hardware init. Thanks for correcting me.


> Aside from just this, OVMF is an effort to support VMs on edk2.  (Ie,
> more than just QEMU.)  Ideally the project, and code of OVMF could be
> used by any VM vendor as a sample for building UEFI compatible
> firmware.
>   

How does it relate to real hardware? You mention OVMF as an effort to
support VMs on edk2. Does this mean that VMs need special support or
that real hardware has different needs?


> Most of the code required to support QEMU was already open sourced on
> edk2 before OVMF was launched.  At the time that we started OVMF, it
> did not seem like any project was targeting UEFI support on QEMU.
> Tristan Gingold had done a port for UEFI QEMU support, but at that
> time it did not seem to be functional with the current QEMU, nor
> actively developed.
>   

I see.


>> I'd like to understand the reasons for that and fix
>> them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS).
>>     
>
> If you want to remove any need for OVMF on QEMU, then I think all that
> is needed is to support booting UEFI OS's for both i386 and x86-64.
> Of course, we may still have some use for the OVMF project on edk2 as
> a sample platform.
>   

Given that my original statement incorrectly assumed OVMF was only about
hardware init, please let me try to express what I originally meant (and
which came across with unintended meaning).
I hope to use all EFI support code from OVMF, keep SeaBIOS, and have
coreboot as common hardware init base.


>> If
>> you ported/modified existing code, I'd be interested in the original
>> codebase to learn from it (especially what you had to change).
>>     
>
> As I mentioned above, a good portion of the code was already available
> in edk2.tianocore.org.

Thanks for the pointer.


> Edk2 is BSD licensed, and therefore from a
> licensing perspective should be easy for your project to utilize.
>   

(Speaking with my coreboot hat on.)
The goal of coreboot is not to assimilate and change other projects, but
to provide hardware init for any code which needs it.

After hardware init, it passes control to a payload (SeaBIOS, UEFI,
GRUB2, FILO, Linux, Plan9...). There are no callbacks to coreboot, each
payload is expected to talk to the hardware on its own. Except for ACPI
tables (and a memory map), nothing of coreboot stays in memory after
passing control to that payload. If you want some basic hardware drivers
for your favourite payload, you can use the BSD-licensed libpayload
library in your code, but most payloads (SeaBIOS, GRUB2, ...) have their
own drivers anyway.
Operating systems like Linux and Plan9 which do not need any BIOS/EFI
interface can be stored in the ROM and will be booted directly by
coreboot (if in ROM). Boot loaders like GRUB2 or FILO don't need
BIOS/EFI either, can be stored in ROM and will then be booted directly.
BIOS and EFI code can be used as a coreboot payload in ROM as well. Some
people are even working on making U-Boot available as coreboot payload.

The idea is to have coreboot handle all the hardware-specific
initialization and allow all other code to be mostly hardware-agnostic
(unless said code wants to implement drivers). The clean interface
(well, no interface, coreboot just passes control to the payload) allows
payloads to do whatever they want as long as they provide a single
32-bit entry point coreboot can jump to.


Regards,
Carl-Daniel