Kevin O'Connor kevin@koconnor.net writes:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
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. The possibility was also raised of a "rom" that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses).
Given the objections to implementing ACPI directly in QEMU, one possible way forward would be to split the current SeaBIOS rom into two roms: "qvmloader" and "seabios". The "qvmloader" would do the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it.
What about a small change to the SeaBIOS build system to allow ACPI table generation to be done via a "plugin".
This could be as simple as moving acpi.c and *.dsl into the QEMU build tree and then having a way to point the SeaBIOS makefiles to our copy of it.
Then the logic is maintained stays in firmware but the churn happens in the QEMU tree instead of the SeaBIOS tree.
Regards,
Anthony Liguori
With both the hardware implementation and acpi descriptions for that hardware in the same source code repository, it would be possible to implement changes to both in a single patch series. The fwcfg entries used to pass data between qemu and qvmloader could also be changed in a single patch and thus those fwcfg entries would not need to be considered a stable interface. The qvmloader code also wouldn't need the 16bit handlers that seabios requires and thus wouldn't need the full complexity of the seabios build. Finally, it's possible that both ovmf and seabios could use a single qvmloader implementation.
On the down side, reboots can be a bit goofy today in kvm, and that would need to be settled before something like qvmloader could be implemented. Also, it may be problematic to support passing of bios tables from qvmloader to seabios for guests with only 1 meg of ram.
Thoughts? -Kevin