[SeaBIOS] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

[Michael S. Tsirkin]

On Tue, May 14, 2013 at 08:34:43AM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst at 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.

So if you tell BIOS how to map slots to nodes it can
generate SRAT. Fine but it still never needs to discover
which hardware is there.

> 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