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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
