From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcFFK-0004Nk-7B for qemu-devel@nongnu.org; Tue, 14 May 2013 09:26:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcFFI-0001NN-P7 for qemu-devel@nongnu.org; Tue, 14 May 2013 09:26:26 -0400 Received: from mail-oa0-f51.google.com ([209.85.219.51]:62553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcFFI-0001N3-JL for qemu-devel@nongnu.org; Tue, 14 May 2013 09:26:24 -0400 Received: by mail-oa0-f51.google.com with SMTP id f4so583612oah.10 for ; Tue, 14 May 2013 06:26:23 -0700 (PDT) From: Anthony Liguori In-Reply-To: <519203F7.8090200@redhat.com> References: <87sj1qboo4.fsf@codemonkey.ws> <519203F7.8090200@redhat.com> Date: Tue, 14 May 2013 08:26:21 -0500 Message-ID: <87sj1p1yma.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Gerd Hoffmann Cc: seabios@seabios.org, lersek@redhat.com, qemu-devel@nongnu.org, "Michael S. Tsirkin" Gerd Hoffmann writes: > Hi, > >>> Several future developments that this will enable: >>> - make it easier to use alternative firmware: >>> any firmware can just load the ACPI tables from QEMU. >>> case in point OVMF. >> >> UEFI obviously can create ACPI tables already so I don't think this is a >> valid advantage. > > Yea, but it doesn't do all the patching seabios does, so some features > simply don't work. Generating the tables in qemu instead will zap those > differnces and will make it alot easier to bring all firmware images > (seabios, ovmf, coreboot, ...) to feature parity without duplicating the > code needed for that in all firmwares. The fact that different firmwares duplicate functionality is the based on the fact that the different firmwares inheritently duplication functionality by the virtue of being different projects. >> You could use this argument to say that QEMU should implement int13 or >> int10 too... > > This is comparing apples and oranges. > >> This has strong analogies to generating device trees > > Indeed, both acpi and device trees describe the hardware emulated by > qemu. Comparing acpi + device trees makes alot more sense than > comparing acpi with int10 ... > >> and is also a good >> reason why exposing this information via a common interface (fw_cfg) >> would be a good idea. > > Huh? As far I know we generate device trees in qemu instead of > expecting pseries firmware compile them from fw_cfg information. It depends on what firmware you are using. We don't really generate device trees in general in QEMU. As Peter mentioned, in an ideal world we'd generate them from the QOM graph. That should happen in the firmware and it could be enabled by adding just a couple fw_cfg commands to navigate the QOM graph (analogs to qom-list and qom-get in QMP). Regards, Anthony Liguori > > cheers, > Gerd