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@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.