Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

[Anthony Liguori <anthony@codemonkey.ws>]

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