Re: [Qemu-devel] Release plan for 0.12.0

[Carl-Daniel Hailfinger]

[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. 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 ported/modified existing code, I'd be interested in the original
codebase to learn from it (especially what you had to change).


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