From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ujdvp-0007dR-Ie for qemu-devel@nongnu.org; Mon, 03 Jun 2013 19:13:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UjdvW-0002gr-4l for qemu-devel@nongnu.org; Mon, 03 Jun 2013 19:12:53 -0400 Received: from mail-gg0-x232.google.com ([2607:f8b0:4002:c02::232]:62624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjdvV-0002gl-VT for qemu-devel@nongnu.org; Mon, 03 Jun 2013 19:12:34 -0400 Received: by mail-gg0-f178.google.com with SMTP id a5so1254681ggn.23 for ; Mon, 03 Jun 2013 16:12:33 -0700 (PDT) From: Anthony Liguori In-Reply-To: References: <87sj1qboo4.fsf@codemonkey.ws> <20130514115838.GA24176@redhat.com> <87ppwt1y8c.fsf@codemonkey.ws> Date: Mon, 03 Jun 2013 18:12:30 -0500 Message-ID: <87bo7m94bl.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: Jordan Justen Cc: seabios@seabios.org, Laszlo Ersek , qemu-devel , "Michael S. Tsirkin" Jordan Justen writes: > On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori wrote: >> "Michael S. Tsirkin" writes: >> >>> 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. >>> >>> Just to clarify: generating ACPI tables is not BIOS >>> functionality. It ended up in seabios for historical >>> reasons. >>> >>> A normal scenario for ACPI tables is that they are written >>> in ASL and compiled with IASL. >> >> I wouldn't call this the normal scenario. Some tables are static but >> more tables are dynamic than you'd think. If you're a firmware engineer >> and you have to support dozens of platforms, it's much easier to make >> the tables dynamic than attempt to maintain dozens of ASL descriptions. > > Anthony is right. Firmware for "real" systems contains the tables as > binary aml output from the asl compiler, but also goes through > extensive hoops to tweak the ACPI information. > > On the other hand, "real firmware" doesn't have the luxury of being > able to just download the ACPI tables like fw-cfg might be able to > offer. > > I'm a little concerned that firmware might find a desire to still > customize the tables, and thus the fw-cfg solution might be too > restricting. It does seem to work out okay for other VMM projects > though. (It does seem to be working for Xen in OVMF. But, I'm not > certain how well it is working, since I don't have a Xen setup.) > > I mentioned in the other thread that perhaps QEMU could also consider > making the ACPI code available under some 'appropriate' license, which > would allow firmware writers to leverage the code directly if desired. > Perhaps a dual/multi license situation for the relevant files? Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree? I think the only solution to the licensing problem is a GPL-friendly UEFI build... Regards, Anthony Liguori > > But, if the fw-cfg route works, then it seems the easiest option for > firmware writers. > > -Jordan