Gerd Hoffmann wrote:
- Significant amounts of code can quite likely be shared between
many different hypervisors, since coreboot already shares significant code between many different hardware platforms, never mind the reuse possible across *both* hypervisors and hardware.
Not really.
Yes, really.
Virtual hardware can be reconfigured in ways which is impossible on real hardware. This is (party) where the complexity we have in seabios wrt. acpi comes from.
Yes. And the more flexibility is required the more complex the code gets. It sounds like there will soon be need for a more generic PCI resource allocator, which is another thing that coreboot already has.
- Having (many!) hypervisor-specific special cases in SeaBIOS seems
wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*.
It's a tradeoff. On one hand letting coreboot handle hardware initialialization would reduce the amout of code in seabios we have to maintain. On the other hand adding coreboot as middle man between qemu and seabios would add some complexity to the whole mix.
What complexities have you run into?
coreboot can of course be improved further, but as you may know SeaBIOS gets built by default by the coreboot build process already, so using coreboot wouldn't even add extra steps for a manual build.
I'm not convinced using coreboot is a clear win, especially with EFI coming. Can coreboot run tianocore as payload?
Work is ongoing to make edk2 a good coreboot payload. It already works for some values of works, but more work is needed. Progress has been fast the last month or so, thanks to efforts by David and Patrick Georgi.
ACPI not working at all in linux guests when using coreboot with seabios payload doesn't exactly encourage exploring that option btw.
Then the way the QEMU mainboard does ACPI in coreboot needs fixing, which is quite possible because I don't know if someone has actually implemented ACPI at all for QEMU, and if so it is not likely using the more modern facilities but likely to have static ASL. The point is not what is already there, the point is that adding this stuff into SeaBIOS or QEMU for that matter would mean re-inventing *yet another* wheel which is *already* finished in coreboot.
but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init.
Well, *this* discussion is about moving stuff *out* of seabios.
Good point, but it seems to be about moving stuff into each respective hypervisor, when in fact much of that code could probably be common in coreboot without significant effort.
//Peter