My background is that of a strong coreboot proponent.
Gleb Natapov wrote:
So why not go further? In theory qemu needs seabios only for legacy bios functionality. Qemu is perfectly capable of configuring HW to OS usable state by itself, so we can have coreboot functionality completely inside qemu and use seabios only for legacy function just like coreboot does.
I think this is a really interesting idea, IMO it makes qemu an even more complete product.
Firmware/HW is tightly coupled by design. If you do not want seabios to be qemu's firmware and just what it to have only legacy bios functionality we can yank all qemu support from seabios and move it to coreboot project and use seabios only for legacy bios just like coreboot does.
Personally I believe the life of SeaBIOS would be easier if it didn't have to be both a qemu firmware and a BIOS service provider, but note that I am not a SeaBIOS developer.
I think it would be very cool if qemu required a coreboot payload for startup instead of a complete firmware. Then SeaBIOS could focus only on the coreboot model, and only on being an excellent BIOS service provider.
But at some point the firmware/init part might be better placed in coreboot, if the coreboot infrastructure is useful enough. I don't know enough about "proper" qemu init to say if that's actually the case though.
I think it's important to keep the coreboot model in mind, where firmware and BIOS are very much distinct entities.
You don't changed you HW when you update you BIOS in non virtualized world.
No, but you may not be able to get the very latest firmware either, because of limitations in the hardware that the BIOS developers knew about, and thus chose not to include in the updated BIOS.
The information required to make this choice comes from the hardware department.
For qemu firmware (whether in qemu, coreboot or SeaBIOS) it means that info about the hardware must be available in order to selectively enable or implement stuff in the firmware and/or in the BIOS.
You do change you BIOS with each new HW though.
But that is not because of any technical reasons, only because the BIOS developers keep one code base per hardware, and because the hardware can not completely describe itself.
qemu could do that, and if firmware and BIOS service provider understands the description then there's no reason to change firmware nor BIOS just because the hardware changes. I think that would be very elegant. :)
Kevin O'Connor wrote:
That depends on how you view seabios project. If you consider it to be legacy bios functionality provider only then I agree and we should move to coreboot model. If you consider it to be legacy bios + qemu firmware (like old BOCHS bios was) then by definition it's seabios job to describe underlying HW to an OS.
I don't think this is that "cut and dry". A real machine just ships with these acpi tables compiled in. This is what BOCHS bios did and it is what seabios did up until about 8 months ago.
However, qemu isn't a simple machine emulator - it can emulate a whole class of x86 machines. It's not practical to compile a seabios.bin file for every permutation of x86 machine that qemu can emulate. So, we pass info from qemu to seabios so that it can support all the classes of hardware. This isn't what real machines do, and it's not what bochs bios did.
I do view SeaBIOS as primarily a legacy bios interface and a boot loader. I also think it makes sense to handle qemu and kvm firmware needs - some initialization wants to be done from the guest and seabios is a good place to do that.
I don't care at all strongly about this, but when considering the coreboot model, then then qemu firmware part seems to fit better in the coreboot project. But again let me emphasize that I'm just as happy with it being in SeaBIOS. :)
This hpet thing is really rather minor, but it has me puzzled. The guest OS wants the info in ACPI form, and only qemu has the info. I don't understand why there is a desire to pass the info in this new arbitrary form instead of passing it in the form that the OS wants it in.
I guess the reason is to create a separate interface between hardware and firmware. This is information that is normally communicated out-of-band between hardware engineers and firmware engineers, and now it wants to be done at runtime. I think this is a great improvement, and maybe it can even benefit PC hardware universally. :)
//Peter