From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui5td-00017t-FS for qemu-devel@nongnu.org; Thu, 30 May 2013 12:40:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui5tX-0006ar-AE for qemu-devel@nongnu.org; Thu, 30 May 2013 12:40:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui5tX-0006aV-27 for qemu-devel@nongnu.org; Thu, 30 May 2013 12:40:07 -0400 Message-ID: <51A78152.10000@redhat.com> Date: Thu, 30 May 2013 18:41:54 +0200 From: Laszlo Ersek MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 , "Jordan Justen (Intel address)" , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , "Michael S. Tsirkin" , Gerd Hoffmann , Anthony Liguori , David Woodhouse On 05/30/13 18:20, Jordan Justen wrote: > 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? 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, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. Laszlo