Hi,
Raised that QOM interface should be sufficient.
Agree on this one. Ideally the acpi table generation code should be able to gather all information it needs from the qom tree, so it can be a standalone C file instead of being scattered over all qemu.
Ack. So my basic argument is why not expose the QOM interfaces to firmware and move the generation code there? Seems like it would be more or less a copy/paste once we had a proper implementation in QEMU.
Well, no. Firmware is a quite simple environment without standard libc etc, so moving code from qemu to firmware certainly isn't as easy as copying over a file.
There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS.
Certainly an option, but that is a long-term project.
Out of curiousity, are there other benefits to using coreboot as a core firmware in QEMU?
Short-term it's alot of work as we have to bring coreboot's qemu support to feature parity with seabios. I suspect most of this is acpi related though, so when qemu provides the tables and coreboot uses them we could be pretty close already.
Long-term it should simplify firmware maintainance as we have only *one* place which handles the hardware bringup, and seabios/ovmf have less work to do.
Is there a payload we would ever plausibly use besides OVMF and SeaBIOS?
I wouldn't be surprised if people start using other coreboot payloads and/or features such as direct linux kernel boot once it works well on qemu.
We might even run qemu test suites as coreboot payload.
cheers, Gerd