On 05/31/13 10:13, Peter Stuge wrote: > Kevin O'Connor wrote: >> 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. > > qvmloader sounds a lot like coreboot. Indeed. > ACPI bytes are obviously a function of QEMU configuration. QEMU > configuration can be changed through a great many channels, so it > makes sense to me that QEMU itself would take care of generating > correct ACPI, rather than exporting it's own data structures and > pushing the ACPI problem onto the firmware, especially considering > the desire for multiple independent firmware implementations. Can't agree more. I still think the best solution is to have qemu generate the acpi tables and all firmware can just grab them. Second best option would be to have coreboot generate them and everything else go on top of coreboot then. Third best option is to duplicate the acpi generation code in all firmware variants (this is what we have today). IMO qvmloader would be even worse than these three. Writing a piece of firmware is alot more tricky than a linux userspace app, especially in x86 land with the funky mode switching and assembler modes. 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
