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

[Kevin O'Connor <kevin@koconnor.net>]

On Tue, Jun 15, 2010 at 07:41:02AM +0300, Avi Kivity wrote:
> On 06/14/2010 09:25 PM, Kevin O'Connor wrote:
> >This seems to be a philosophical distinction.  Lets go over the
> >practical implications.
> In my experience, well-defined interfaces ("philosophical
> distinctions") are more important in the long term than
> practicalities.

I agree with the importance of clean interfaces.  However, I feel the
current approach to acpi table handling between qemu and seabios is
not ideal.  I'm proposing an interface which I believe is an
improvement.

> If a table needs to refer to some other information which is in a
> table that is generated by seabios, we cannot generate this table
> from qemu.  That's much worse that reviewing and applying two
> patches.

I understand.  Such tables would not make sense to generate in qemu.

I also understand and appreciate the desire for qemu to not touch
guest memory.  This means rsdp and rsdt are the domain of seabios.
The only other table that directly addresses the memory location of
another table (that I know of) is fadt - which is also tied to
seabios' smi handler - so this too is in seabios' domain.

I'm not aware of any dependencies to seabios in any of the other
tables (eg, madt, srat, hpet, ssdt, dsdt).

> >I'm not suggesting a radical rethink of fwcfg, but I fail to see the
> >advantage in introducing the arbitrary "struct hpet_fw_entry" when
> >there is a perfectly good, well defined, "struct acpi_20_hpet" that
> >already exists.  This new arbitrary intermediate format just
> >introduces "make work" for all of us.
> 
> Choosing an existing format is fine.  But seabios blindly copying
> qemu provided data is wrong IMO.

Okay.  For "struct acpi_20_hpet", what transformations or checks do
you think seabios needs to perform?

-Kevin