[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Date: Tue, 14 May 2013 08:34:43 -0500
User-agent: Notmuch/0.15.2+77~g661dcf8 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

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

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.


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?
> -- 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]