From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmJ7K-0002YT-Iv for qemu-devel@nongnu.org; Tue, 11 Jun 2013 03:35:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmJ7H-0002mK-Oo for qemu-devel@nongnu.org; Tue, 11 Jun 2013 03:35:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmJ7H-0002mB-9O for qemu-devel@nongnu.org; Tue, 11 Jun 2013 03:35:43 -0400 Date: Tue, 11 Jun 2013 10:35:48 +0300 From: "Michael S. Tsirkin" Message-ID: <20130611073548.GE31474@redhat.com> References: <1370882347-31129-1-git-send-email-mst@redhat.com> <87r4g9rdwe.fsf@codemonkey.ws> <51B62C48.5060303@redhat.com> <87ehc920ym.fsf@codemonkey.ws> <51B63A74.1030905@redhat.com> <87mwqxzlke.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , David Woodhouse , seabios@seabios.org, qemu-devel , Kevin O'Connor , Gerd Hoffmann , Jordan Justen , Laszlo Ersek On Mon, Jun 10, 2013 at 08:03:46PM -0500, Anthony Liguori wrote: > >> It is not "supported" by QEMU. > > > > No, but I've always thought that QEMU was happy to have alternative > > firmware projects. > > We are and we're happy to accept patches to enable things even if its > proprietary. But that's all assuming we're improving hardware > emulation. > > What we're talking about here is doing something that's very un-hardware like. Two points 1. You never explained what you mean by un-hardware like. Currently bios is in a ROM device, and it has a template for ACPI tables together with it. This simply moves the tables to a separate ROM device (FW CFG), and generalizes the template using the linker interface. One ROM is hardware-like but two is un-hardware like? ACPI tables are static so it's likely lots of hardware has at least some of them pre-formatted in flash, then tweak some things like SRAT a bit. 2. There's no hardware-like alternative. A current alternative is exposing lots of PV interfaces to bios, bios builds up ACPI tables based on them. All of this code is in practice PC only, if we ever attempt to generalize we'll see how the interfaces are not a good match. They are still PV, poorly documented and it's very hard for bios not to make any assumptions about them. When it does, result is a very obscure breakage. Yes, building tables in bios means QEMU code is simpler but we double the amount of interfaces that we need to get right: QEMU-BIOS + BIOS-OS Yes it's "not QEMU code" but it's seen as a single package by users and it does not really matter - excellent hardware with lousy firmware is useless. -- MST