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

[Anthony Liguori <anthony@codemonkey.ws>]

"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.

A lot of what you'd consider to be static is actually dynamic in a
multi-node system.

> The tables are then stored
> in some ROM device - most of them, except FACP, can actually
> be mapped directly from ROM if necessary.
>
> You won't normally find real BIOS probing PCI slots for
> hotplug support and writing EJ0 methods dynamically -
> instead the assumption is that hardware (in this case QEMU)
> supplies its own static description in form of ACPI tables.

Actually, this is a very good example.  In more modern boxes like Flex,
there's a PCI-Express backplane that all of the nodes are connected to
with a common set of slots for all nodes.  You can configure in firmware
how the slots map to each node.

I can share an acpi dump from one of these systems when after I head
into the office this morning.

This is what's nice about a switched PCI complex.  You have tremendous
amounts of flexibility in how you set things up.

Regards,

Anthony Liguori

> My patchset uses FW_CFG as such a ROM device. It would be
> easy to switch to something else instead of FW_CFG.
> Is this what you are suggesting?
>
> -- 
> MST