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