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? This also needs to be resolved for SSDT tables, which can have zero, one, or more instances.
How about we don't bother to determine this at runtime at all? Long term all tables will be in qemu so why bother with a runtime mechanism just for an intermediate stage? Just build BIOS with the correct flags.
Finally, the mechanism should define how the RSDP signatures is set as well as support both RSDT and XSDT tables (with signatures defined by QEMU for these as well).
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. 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.
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.
Thoughts?
-Kevin
Yes I agree these tables need some thought. But first things first, we can move quite a lot of code out to qemu with just fw_cfg.