Re: [SeaBIOS] KVM call agenda for 2013-05-28
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.
qvmloader could be committed into the QEMU repo and maintained there.
If QEMU really doesn't want anything besides quacking like a PC with BIOS or UEFI (such as quacking like a PC *without* a particular firmware) it makes perfect sense to me to put the complete firmware code into the QEMU repo and never reuse anything else. After all, that's how the proprietary firmware products are managed. Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
I don't know about burden but to me it just doesn't make any sense to generate ACPI in one component (SeaBIOS) based on configuration for another component (QEMU). 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. There's some code for dynamic ACPI generation in coreboot already, maybe that can be reused in QEMU to save some effort..
On the flip side, why is moving the ACPI tables to QEMU such an issue?
Maybe because it is such a steaming pile that even the place where it belongs doesn't really want it..
I think overall I prefer the tables being built in the firmware, despite the extra thrash.
That doesn't make sense to me. :\ Keep in mind: there is firmware and there is firmware..
Some things, such as the addresses where devices are configured at are re-programmable in QEMU, so a firmware can decide to use a different address, and thus invalidate the address qvmloader had set in the tables.
..there is now talk about a first-stage firmware (qvmloader) which does only hardware init, and then jumps into a second-stage firmware (SeaBIOS) which starts the operating system. I don't expect that anyone would argue for the second-stage firmware to generate ACPI tables if the first-stage firmware would be shared across different second-stage implementations. The above is by the way *exactly* the model coreboot uses since 14 years. Please make an ernest effort to *look into and try to reuse* what *is already there* .. The fear of coreboot is truly amazing. //Peter
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
On 05/31/13 10:13, Peter Stuge wrote:
ACPI bytes are obviously a function of QEMU configuration.
Precisely! When we evaluate that (mathematical-sense) function in boot firmware, we need to retrieve the function's arguments. Those arguments are bits of QEMU configuration, as you say, and fw_cfg is extremely inconvenient for fetching them. Whenever the domain or arity of said "mathematical" function changes (we need more arguments, or different kinds of arguments), we have to extend fw_cfg with yet another ad-hoc key or file entry. The set of arguments going into ACPI tables *is* ad-hoc and arbitrary, there's nothing to do about it. But at least we shouldn't impede the retrieval of said arguments with artificial obstacles, such as half-assedly serializing them over fw_cfg (and not documenting them, naturally). In qemu the entire pool of arguments, current and future, would be at just an arm's length, in immediately consumable form. I've said the same about the acpi_build_madt() prototype that was proposed for qemu: <http://thread.gmane.org/gmane.comp.emulators.qemu/207171/focus=208719>. Thanks, Laszlo
On Fri, May 31, 2013 at 10:13:34AM +0200, 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.
Agreed. I don't much like the qvmloader idea. I did want to open up discussion on the possibility, however. The only advantage it has over coreboot is that it could reasonably live in the qemu repo, and I do think that the hardware descriptions should like in the same code repo as the hardware implementation. -Kevin
participants (4)
-
Gerd Hoffmann -
Kevin O'Connor -
Laszlo Ersek -
Peter Stuge