[SeaBIOS] [PATCH 2/2] accept MADT over fw_cfg

[Kevin O'Connor]

On Thu, Mar 21, 2013 at 09:18:50AM +0100, Gerd Hoffmann wrote:
> On 03/21/13 07:23, Michael S. Tsirkin wrote:
> > On Wed, Mar 20, 2013 at 08:22:30PM -0400, Kevin O'Connor wrote:
> >> On Wed, Mar 20, 2013 at 10:53:05PM +0100, Laszlo Ersek wrote:
> >>>
> >>> Signed-off-by: Laszlo Ersek <lersek at redhat.com>
> >>
> >> I think we need to figure out what the final fw_cfg interface for
> >> ACPI, SMBIOS, mptable, and PIR will be.
> >>
> >> We can use the current fw_cfg ACPI table passing mechanism for ACPI,
> >> but there are a couple of things that need to be worked out.  For each
> >> table, there must be a way to determine if SeaBIOS should build it, or
> >> if the table should not be present at all.  For example, if MADT isn't
> >> present in the fw_cfg, is that because SeaBIOS is expected to build it
> >> or because it is not expected to be present at all?
> 
> I think we always have a MADT, don't we?  So why worry about the case
> that we might have no MADT?  I think the logic is just fine here.

It's not always the case that we have an HPET or an SRAT though.  (And
potentially one may wish to test cases where the MADT is not present.)

> >> This also needs
> >> to be resolved for SSDT tables, which can have zero, one, or more
> >> instances.
> 
> Same argument as for the MADT.

The issue with the SSDT is that there can be many of them.  QEMU may
wish to pass in 2 or more.  If QEMU does pass in one or more SSDTs,
how will SeaBIOS know if it should also generate it's own SSDT?

> >> For mptable and
> >> PIR, there is no current mechanism, so we can add new fw_cfg "files"
> >> for them.  However, for all of these SeaBIOS needs to be able to
> >> determine when it needs to create the table and when no table should
> >> be published at all.
> 
> Same argument as for the MADT.

I'm not sure about that.  Right now the PIR table on q35 is totally
bogus - it would assuredly be better to not produce a PIR table then
to produce an incorrect one.  Maybe the right solution here is to fix
the PIR on q35, but I would not be surprised if at some point it
became impossible to define a valid PIR for new hardware.

> >> One possible way to accomplish the above would be to add an
> >> "all_tables_from_qemu" fw_cfg entry that turned off all of the
> >> existing SeaBIOS code.  There are probably other ways.
> 
> As this is quite a bunch of work I would tend to avoid a flag day like
> this so we can switch over tables one by one without building up big
> patch queues.

True.  I'm certainly open to ideas.

In practice, one never wants to mix QEMU generated ACPI tables with
SeaBIOS generated ACPI tables.  To do so would be chaos - the
signatures and versions would likely not match, various code
assumptions could conflict, and basic things like knowing where to
report a bug would be overly complex.

So, I wouldn't want to have to merge all patches in one big "flag
day", but maybe, for example, the new QEMU tables should be sent via
new fw_cfg entries and SeaBIOS should only be updated to use these new
entries once everything is produced by QEMU.

As an aside, there is some mixing of tables already because of the
qemu "-acpitable" option.  However, this is relatively limited and
done solely to import external system tables to appease certain guests
- it will always be an external mixing of tables because of this.
(The DSDT import isn't mixing tables - the DSDT is generated in
SeaBIOS to be used with other SeaBIOS tables - it's just a means of
reducing the size of the SeaBIOS binary.)

-Kevin