Hi,
Several future developments that this will enable:
- make it easier to use alternative firmware: any firmware can just load the ACPI tables from QEMU. case in point OVMF.
UEFI obviously can create ACPI tables already so I don't think this is a valid advantage.
Yea, but it doesn't do all the patching seabios does, so some features simply don't work. Generating the tables in qemu instead will zap those differnces and will make it alot easier to bring all firmware images (seabios, ovmf, coreboot, ...) to feature parity without duplicating the code needed for that in all firmwares.
You could use this argument to say that QEMU should implement int13 or int10 too...
This is comparing apples and oranges.
This has strong analogies to generating device trees
Indeed, both acpi and device trees describe the hardware emulated by qemu. Comparing acpi + device trees makes alot more sense than comparing acpi with int10 ...
and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea.
Huh? As far I know we generate device trees in qemu instead of expecting pseries firmware compile them from fw_cfg information.
cheers, Gerd