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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote:
> On Thu, May 30, 2013 at 5:19 AM, David Woodhouse <dwmw2@infradead.org> 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.

Of course ACPI tables are firmware.
Please note that what my patches do is simply supply
templates for ACPI tables on a ROM device separate
from where bios code resides.
bios still tweaks them in minor ways.
I am guessing this is what happens on real hardware too:
most tables pre-generated in ROM, firmware shadows
them and tweaks them in minor ways.

> 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