Hi,
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.
Well, not really. Old guests (winxp & older) don't do very well on pc. Modern ones are better served with q35, because they either don't boot on pc (macos I think) or can use the features of the modern hardware, like pci express.
I still like the idea to have pc machine type provide the older stuff. The hardware we emulate for the pc machine type is old enough that old acpi versions should have no problems describing it.
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.
Since the switch to qemu-generated acpi tables we were able to avoid that kind of lockstep updates, I'd prefer to not loose that.
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.
Hmm, seabios could do the same then, and we would not need a lockstep update?
cheers, Gerd