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