From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57534 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOAq0-0001Ay-VV for qemu-devel@nongnu.org; Mon, 14 Jun 2010 10:40:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOApv-0007vs-Qz for qemu-devel@nongnu.org; Mon, 14 Jun 2010 10:40:32 -0400 Received: from mail2.shareable.org ([80.68.89.115]:55315) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOApv-0007v3-N6 for qemu-devel@nongnu.org; Mon, 14 Jun 2010 10:40:27 -0400 Date: Mon, 14 Jun 2010 15:40:16 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCHv2] load hpet info for HPET ACPI table from qemu Message-ID: <20100614144016.GB9550@shareable.org> References: <20100614083053.GC21797@redhat.com> <20100614135425.GA18002@morn.localdomain> <20100614140959.GI21797@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100614140959.GI21797@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Kevin O'Connor , seabios@seabios.org, qemu-devel@nongnu.org Gleb Natapov wrote: > On Mon, Jun 14, 2010 at 09:54:25AM -0400, Kevin O'Connor wrote: > > Could we just have qemu build the hpet tables and pass them through to > > seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method. > > > Possible, and I considered that. I personally prefer to pass minimum > information required for seabios to discover underlying HW and leave > ACPI table creation to seabios. That is how things done for HW that > seabios can actually detect. If we will go your way pretty soon we will > move creation of ACPI/SMBIOS/MP tables into qemu and IMHO this will be > step backworkds. Why would creation of all the tables in qemu be a bad thing or a step in the wrong direction? Crude argument in favour of doing it in qemu: They're both C code, so sharing code between qemu and SeaBIOS may not be as traumatic as it would be for an asm BIOS. Doing in SeaBIOS forces the existence of another API, in effect, to pass the qemu-specific hardware information, so doing it in qemu means one less interface API that needs designing and maintaining. Argument in favour of doing it all in SeaBIOS: I'm not sure, what is it? Indeed, why not build all the tables outside qemu using a separate tool ("qemu-build-acpi-tables < machine-description.txt"), invoked from qemu when it starts up, making it easier to examine the tables using ACPI tools? -- Jamie