From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] KVM call agenda for 2013-05-28 Date: Thu, 30 May 2013 15:27:22 +0300 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-Transfer-Encoding: 7bit Cc: KVM devel mailing list , Juan Quintela , "Jordan Justen \(Intel address\)" , seabios@seabios.org, qemu-devel qemu-devel , Gerd Hoffmann To: David Woodhouse Return-path: Content-Disposition: inline In-Reply-To: <1369916358.5141.32.camel@i7.infradead.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: seabios-bounces@seabios.org Sender: seabios-bounces@seabios.org List-Id: kvm.vger.kernel.org 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