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

[Jordan Justen]

On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori <address@hidden> wrote:
> "Michael S. Tsirkin" <address@hidden> 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?

But, if the fw-cfg route works, then it seems the easiest option for
firmware writers.

-Jordan