From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcwLU-00018z-Pm for qemu-devel@nongnu.org; Thu, 16 May 2013 07:27:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcwLS-00051S-04 for qemu-devel@nongnu.org; Thu, 16 May 2013 07:27:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcwLR-00051J-PE for qemu-devel@nongnu.org; Thu, 16 May 2013 07:27:37 -0400 Date: Thu, 16 May 2013 14:27:46 +0300 From: "Michael S. Tsirkin" Message-ID: <20130516112746.GA31911@redhat.com> References: <87sj1qboo4.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sj1qboo4.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: seabios@seabios.org, lersek@redhat.com, qemu-devel@nongnu.org On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: > I don't think it's a good idea to move BIOS functionality in QEMU. > > We don't frequently add firmware or chipsets so it seems like we're > optimizing for an uncommon scenario here. > > Regards, > > Anthony Liguori By the way, on x86 we already load some ACPI tables through fw_cfg: hw/i386/pc_piix.c: pc_acpi_init("acpi-dsdt.aml"); hw/i386/pc_q35.c: pc_acpi_init("q35-acpi-dsdt.aml"); so putting all other tables in one place will just make things more consistent. Yes, ACPI is messy, and pc-specific, but IMO that's life: it's better to give guests as much help as we can if it's messy, not push the messiness out for guests to handle. -- MST