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

[Kevin O'Connor]

On Tue, Jun 15, 2010 at 09:37:07AM +0300, Gleb Natapov wrote:
> On Mon, Jun 14, 2010 at 04:12:32PM -0400, Kevin O'Connor wrote:
> > But.. in order to move to a newer ACPI spec, there would be qemu
> > changes anyway.  (If nothing else, so that qemu can tell seabios if
> > it's okay to use the new rev.)  At that point we're stuck changing
> > both repos anyway - nothing gained, nothing lost.
> I don't see why qemu should care what ACPI rev Seabios uses.

A change in ACPI rev would likely break old OSs.  Only the user would
know this, and so a method of propagating that info from qemu to
seabios would be needed.  (However, it's much more likely that a new
ACPI rev would require more data which qemu would then also need to
pass to seabios.)

> > I still think there is an opportunity to reduce the load on the bulk
> > of acpi changes - most of these changes have no dependence on seabios
> > at all.
> 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.

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.

A couple of emails back you stated you considered using the existing
qemu_cfg_acpi_additional_tables() format but dismissed the idea.
Maybe you could explain why you dismissed it and/or what the
deficiencies of this mechanism are?

-Kevin