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

[Michael S. Tsirkin]

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.
> 
> Having a debug printk saying which table came from there would be nice
> for trouble shooting though.
> 
> >> This also needs
> >> to be resolved for SSDT tables, which can have zero, one, or more
> >> instances.
> 
> Same argument as for the MADT.
> 
> > How about we don't bother to determine this at runtime at all?
> 
> Because it will be a PITA for testers + developers to figure the correct
> .config switches of the day during the transition phase?

Why is it a PITA?  Are you developing QEMU?  Just use the makefile from
roms/config.seabios Are you using QEMU binary?  Just use the defaults.

> >> For SMBIOS, I don't think we should use the existing fw_cfg mechanism.
> >> It's too complicated for what is needed.  Instead, one fw_cfg "file"
> >> entry with the whole smbios table should suffice.
> 
> Agree.
> 
> >> 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.
> 
> >> 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.
> 
> Once all is done switched over we can add a .config option for the
> seabios acpi table generation code, so it can be turned off altogether
> for qemu versions new enougth.
> 
> cheers,
>   Gerd

Agree. But no need for a runtime hack.  People building seabios for qemu
should use the makefile from roms/config.seabios we can flip switches
there atomically with adding tables to QEMU.


-- 
MST