(4) would be acceptable I guess. However I think it's a bit worse because fw-cfg files are a somewhat scarce resource. The "legacy" aspect is something that SeaBIOS is in the best position to address, because it knows what OSes are running on it; QEMU instead only takes care of describing the hardware.
SeaBIOS is used with both modern and legacy OSes, and it doesn't have any knowledge about what kind of OS will be used. If anything, I'd argue that QEMU has more knowledge about the guest OS than SeaBIOS does (due to command-line options like machine version).
No, the machine type is independent from the guest OS. The aim is to let "qemu-system-x86_64 -m MEMORYSZ image.qcow2" work just fine with every guest OS.
As I see it, fundamentally the proposal here is to deploy different ACPI tables when using SeaBIOS then when using OVMF. I think that's fine, but I think we should directly address that issue then.
The different ACPI tables are essentially a bug in OVMF. They can be fixed to be the same.
Specifically, I have the following concerns with the original approach:
A - It would require deploying SeaBIOS and QEMU in lock-step. To get this in for QEMU v2.10 would require making QEMU changes during the soft freeze and would require a SeaBIOS "stable" release that introduces ACPI table manipulation.
Yes.
B - I don't have full confidence the proposed ACPI changes wont expose a quirk in some obscure OS from the last 25 years. If it does expose a quirk, any work-around would likely require deploying a new SeaBIOS and QEMU in lock-step.
Well, the solution is proposed by ACPI itself, and the worst that can happen is that some OS prefers the RSDT to the XSDT (which we already test on Windows 2000).
C - We'd be introducing "shared ownership" of the acpi tables. Some of the tables would be produced by QEMU and some of them by SeaBIOS. Explaining when and why to future developers would be a challenge.
The advantage is that the same shared ownership is already present in OVMF. The RSDP/RSDT/XSDT are entirely created by the firmware in OVMF. (The rev1 FADT isn't but that's just missing code; the table manager in general would be ready for that). In any case this doesn't seem like something that cannot be solved by code comments.
Paolo