Gerd Hoffmann kraxel@redhat.com writes:
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.
The fact that different firmwares duplicate functionality is the based on the fact that the different firmwares inheritently duplication functionality by the virtue of being different projects.
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.
It depends on what firmware you are using.
We don't really generate device trees in general in QEMU.
As Peter mentioned, in an ideal world we'd generate them from the QOM graph. That should happen in the firmware and it could be enabled by adding just a couple fw_cfg commands to navigate the QOM graph (analogs to qom-list and qom-get in QMP).
Regards,
Anthony Liguori
cheers, Gerd