From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiYK0-0005ok-Pm for qemu-devel@nongnu.org; Fri, 31 May 2013 19:01:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiYJy-0004BP-2j for qemu-devel@nongnu.org; Fri, 31 May 2013 19:01:20 -0400 Received: from mail-ie0-x22d.google.com ([2607:f8b0:4001:c03::22d]:55378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiYJx-0004BI-Uc for qemu-devel@nongnu.org; Fri, 31 May 2013 19:01:18 -0400 Received: by mail-ie0-f173.google.com with SMTP id k13so5582118iea.4 for ; Fri, 31 May 2013 16:01:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <51A86E3F.5030803@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> <51A78152.10000@redhat.com> <51A86E3F.5030803@redhat.com> Date: Fri, 31 May 2013 16:01:16 -0700 Message-ID: From: Jordan Justen Content-Type: text/plain; charset=ISO-8859-1 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: Gerd Hoffmann Cc: KVM devel mailing list , Juan Quintela , Laszlo Ersek , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , "Michael S. Tsirkin" , Anthony Liguori , "Jordan Justen (Intel address)" , David Woodhouse On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann wrote: > Hi, > >> I guess -bios would load coreboot. Coreboot would siphon the data >> necessary for ACPI table building through the current (same) fw_cfg >> bottleneck, build the tables, > > Yes. So, this is really about making coreboot+seabios the default QEMU firmware, and making seabios depend on being a coreboot payload? >> load the boot firmware (SeaBIOS or OVMF or >> something else -- not sure how to configure that), It wouldn't be loading OVMF. It would be loading CorebootPkg. OVMF is a better sample platform for EDK II since it shows a more realistic view of what an EDK II based platform looks like on real hardware. Thus, if the ACPI tables are just being added to a new coreboot layer with coreboot becoming the default QEMU firmware, then it doesn't help OVMF (or other non-coreboot payloads). Well, it could if the table code was BSD licensed, but only so we could then merge them into OVMF. Then again, why not just provide a set of suitably licensed ACPI source files within the QEMU tree that firmware projects could use? QEMU doesn't necessarily need to build/link them, or attempt to communicate them at runtime. -Jordan > The coreboot rom has named sections (this is called cbfs which stands > for coreboot filesystem IIRC): > > rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print > bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 > alignment: 64 bytes > > Name Offset Type Size > cmos_layout.bin 0x0 cmos_layout 1160 > fallback/romstage 0x4c0 stage 14419 > fallback/coreboot_ram 0x3d80 stage 37333 > config 0xcfc0 raw 2493 > fallback/payload 0xd9c0 payload 56969 > vgabios/sgabios 0x1b8c0 raw 4096 > (empty) 0x1c900 null 144216 > > where "fallback/payload" is seabios. > >> and pass down the >> tables to the firmware (through a now unspecified interface -- perhaps >> the tables could even be installed at this point). > > As far I know coreboot can add more stuff such as acpi tables to cbfs at > runtime and seabios able to access cbfs too and pull informations from > coreboot that way. > > HTH, > Gerd > >