From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui6uI-00043O-C5 for qemu-devel@nongnu.org; Thu, 30 May 2013 13:45:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui6u6-0005cy-7P for qemu-devel@nongnu.org; Thu, 30 May 2013 13:44:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui6u5-0005cb-Vh for qemu-devel@nongnu.org; Thu, 30 May 2013 13:44:46 -0400 Date: Thu, 30 May 2013 20:44:05 +0300 From: "Michael S. Tsirkin" Message-ID: <20130530174405.GE29091@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws> <1369905828.20691.50.camel@shinybook.infradead.org> <51A73459.2020407@redhat.com> <1369916358.5141.32.camel@i7.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: KVM devel mailing list , Juan Quintela , David Woodhouse , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , Gerd Hoffmann , Anthony Liguori , "Jordan Justen (Intel address)" , Laszlo Ersek On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote: > On Thu, May 30, 2013 at 5:19 AM, David Woodhouse 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: > >> .) > > > > 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