"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