Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

[Jordan Justen]

On Thu, May 30, 2013 at 5:19 AM, David Woodhouse <address@hidden> wrote:
> On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
>> Where is CorebootPkg available from?
>
> https://github.com/pgeorgi/edk2/tree/coreboot-pkg

Is the license on this actually BSD as the License.txt indicates?

Is this planned to be upstreamed?

Does this support UEFI variables?

Does this support UEFI IA32 / X64?

>> > And it helps to dispel the stupid misconception in some quarters that
>> > Coreboot *competes* with UEFI and thus cannot possibly be supported
>> > because helping something that competes with UEFI would be bad.

Coreboot and EDK II both provide a good infrastructure for
initializing hardware. So, they compete on that point.

Coreboot then focuses on booting coreboot payloads, while EDK II
focuses on UEFI support. On that point they don't compete, but the
focus is different.

Of course, you can build a layer of EDK II => Coreboot payload
support, or Coreboot => EDK II (CorebootPkg, I guess?), but the match
will not be perfect. (That is not to say it can't work.)

>> I'm not sure who do you mean by "some quarters", but for some
>> distributions Coreboot would be yet another component (package) to
>> support, for no obvious benefit.
>>
>> (Gerd said it better than I possibly could:
>> <http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705>.)
>
> Yeah, but if we're shoving a lot of hardware-specific ACPI table
> generation into the guest's firmware, instead of just doing it on the
> qemu side where a number of us seem to think it belongs, then there *is*
> a benefit to using Coreboot. When stuff changes on the qemu side and we
> have to update the table generation to match, you end up having to
> update just the Coreboot package, and *not* having to patch both SeaBIOS
> and OVMF.

I think ACPI table generation lives in firmware on real products,
because on real products the firmware is the point that best
understands the actual hardware layout for the machine. In qemu, I
would say that qemu best knows the hardware layout, given that the
firmware is generally a slightly separate project from qemu.

I don't think adding a coreboot layer into the picture helps, if it
brings along the coreboot payload boot interface as a requirement.

Then again, I don't really understand how firmware could be swapped
out in this case. What would -bios do? How would the coreboot ACPI
shim layer be specified to qemu?

-Jordan