From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui1x6-0004U4-6L for qemu-devel@nongnu.org; Thu, 30 May 2013 08:27:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ui1wx-0002ch-UZ for qemu-devel@nongnu.org; Thu, 30 May 2013 08:27:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ui1wx-0002cM-N9 for qemu-devel@nongnu.org; Thu, 30 May 2013 08:27:23 -0400 Date: Thu, 30 May 2013 15:27:22 +0300 From: "Michael S. Tsirkin" Message-ID: <20130530122722.GC12791@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: <1369916358.5141.32.camel@i7.infradead.org> 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: David Woodhouse Cc: KVM devel mailing list , Juan Quintela , "Jordan Justen (Intel address)" , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , Gerd Hoffmann , Anthony Liguori , Laszlo Ersek On Thu, May 30, 2013 at 01:19:18PM +0100, David Woodhouse wrote: > 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, Hopefully this is not yet set in stone. > 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. We have all kind of logic in qemu. Some of it can thinkably be moved to a separate VM - it doesn't even need to run in the same VM as the guest - we could do it e.g. like kvm unit-test does, with less pain than running it in firmware. Not clear why would generating ACPI tables - which merely fills up an array of bytes from internal QEMU datastructures - should be the part where we start this modularization. -- MST