From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3Kwh-0007z8-Jq for qemu-devel@nongnu.org; Sun, 28 Jul 2013 02:59:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3Kwb-0001Sj-HA for qemu-devel@nongnu.org; Sun, 28 Jul 2013 02:59:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3Kwb-0001SS-7u for qemu-devel@nongnu.org; Sun, 28 Jul 2013 02:59:05 -0400 Date: Sun, 28 Jul 2013 10:00:27 +0300 From: "Michael S. Tsirkin" Message-ID: <20130728070027.GC12087@redhat.com> References: <1374681580-17439-1-git-send-email-mst@redhat.com> <1374681580-17439-15-git-send-email-mst@redhat.com> <51F122D1.4010600@redhat.com> <20130725132301.GA2575@redhat.com> <51F13D0C.20602@redhat.com> <20130725151435.GE3758@redhat.com> <51F23C1A.7030103@redhat.com> <51F29615.7030900@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F29615.7030900@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 14/14] i386: ACPI table generation code from seabios List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Anthony Liguori , qemu-devel@nongnu.org On Fri, Jul 26, 2013 at 05:30:29PM +0200, Gerd Hoffmann wrote: > Hi, > > >> That's something I think that it's best for firmware to avoid. > >> Much better to load tables in memory and use standard ACPI > >> methods to find specific tables. > > > > Problem is this happens relatively late in the firmware boot process. > > Completely different idea to tackle the issue: use COMMAND_ADD_POINTER > not only for table pointers, but also register offsets. So the firmware > doesn't need to parse fadt to figure how it should program pm_base, but > instead can fixup the fadt according to the pm_base it has used. > > That is more in line with how firmware works (pm_base and simliar things > tends to be #defines and are not runtime-configurable). And I think > it's also more robust when extending/changing tables for newer acpi spec > revisions. > > cheers, > Gerd > And for newer chipsets. I agree. I plan to add a file to configure how firmware programs PCI devices at init. -- MST