Re: [Qemu-devel] Release plan for 0.12.0

[Jordan Justen]

On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
<address@hidden> wrote:
> [Adding the coreboot list to CC. Please ignore the moderation messages,
> your addresses will be whitelisted ASAP.]
>
> On 02.10.2009 20:53, Anthony Liguori wrote:
>> Carl-Daniel Hailfinger wrote:
>>> 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.
>>>
>>
>> If you want to to work seamlessly, you need to check for the EFI
>> system partition to see whether it's an EFI capable OS and then
>> fallback gracefully to SeaBIOS boot.
>
> Hm. Wouldn't that be a layering violation (hw init != reading the disk)
> and also cause problems if you want to boot an EFI capable OS from
> SeaBIOS? I can think of someone having an EFI bootable disk image who
> wants to boot that disk image with EFI and BIOS without having to
> repartition.
>
>
>>> 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.
>>
>> Tianocore's OVMF project should provide all the required
>> initialization for EFI on QEMU.
>
> Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS
> for SeaBIOS. That also means each hw init codebase has to support the
> new Q35 chipset proposed for Qemu.
>
> It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you
> have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had
> less testing than the Bochs BIOS or SeaBIOS on Qemu.
>
> 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.

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.

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

> 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.  Edk2 is BSD licensed, and therefore from a
licensing perspective should be easy for your project to utilize.

>
>>> The coreboot solution would also avoid converting SeaBIOS because
>>> SeaBIOS already works as coreboot payload (that's how coreboot
>>> developers call the CSM).
>>>
>>
>> I'll bite, what's the advantage of doing coreboot + SeaBIOS vs.
>> SeaBIOS alone?  Forget about EFI for the moment, should be considering
>> switching to coreboot + SeaBIOS for 0.12?
>
> Advantages:
> - Code coverage increase: SeaBIOS is used with coreboot on real
> hardware, so the BIOS interface part of SeaBIOS gets a lot more testing
> than the Qemu hardware init part of SeaBIOS.
>
> - coreboot supports real 440BX hardware besides Qemu, so the coreboot
> init code is exercised more (and there is still a sizable number of such
> machines around (clusters), many of them running coreboot).
>
> - Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into
> the ROM image and SeaBIOS will automatically load it from there. Same
> for network card ROMs (with gPXE etc.).
>
> - coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS)
> are archives and can be listed/edited with cbfstool if you want to know
> what's in there.
>
> - coreboot ROMs use compression, so you can stuff more code (and PCI
> option ROMs) into smaller ROMs.
>
> - coreboot has pretty verbose hardware init messages (if you want that)
> and can be totally silent as well. The messages end up in a log buffer
> which can be read by the OS (experimental feature, not available by
> default).
>
> There are a lot more advantages, but I want to give other coreboot
> developers a chance to chime in. If you add EFI to the mix, the
> synergies increase.
>
>
> Regards,
> Carl-Daniel
>