Jordan Justen jljusten@gmail.com writes:
On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori anthony@codemonkey.ws wrote:
"Michael S. Tsirkin" mst@redhat.com 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