"Michael S. Tsirkin" <m...@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 _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
