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 <ler...@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 _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios