[Qemu-devel] Re: [SeaBIOS] [PATCHv2] load hpet info for HPET ACPI table from qemu

[Peter Stuge]

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