On Fri, May 31, 2013 at 07:58:36AM -0500, Anthony Liguori wrote: > Kevin O'Connor <kevin@xxxxxxxxxxxx> writes: > > 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. > What about a small change to the SeaBIOS build system to allow ACPI > table generation to be done via a "plugin". Using a runtime plugin (eg, "qplugin") would require a more complex handoff then qvmloader. With qplugin, seabios would need to know what memory qplugin is compiled to run in and make sure it didn't allocate anything there. Similarly, qplugin would need to not stomp on seabios while it runs, and it would need to coordinate with seabios where to place the final tables. With qvmloader, there is no need to coordinate memory addresses, so it can run anywhere, deploy the tables in their final location, and then launch seabios. > 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. I don't see how that would work. It would complicate the seabios build (as it would require a copy of qemu source to compile), and the resulting seabios binary would be strongly tied to the qemu version it was compiled with and vice-versa. This would break distro seabios rpms. It would also cause great pain when bisecting and would be confusing even during regular compile/debug cycles. Internal seabios calls (eg, memory allocations, pci config accesses) would need to be static interfaces, etc. -Kevin -- 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
