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

[Gleb Natapov <gleb@redhat.com>]

On Mon, Jun 14, 2010 at 04:12:32PM -0400, Kevin O'Connor wrote:
> On Mon, Jun 14, 2010 at 09:56:15PM +0300, Gleb Natapov wrote:
> > On Mon, Jun 14, 2010 at 02:25:21PM -0400, Kevin O'Connor wrote:
> > > It seems there was a change in qemu to the hpet functionality.
> > My patch is completely unrelated to functionality change in qemu. In
> > fact I wrote it before the change and had to rebase. Seabios/qemu have
> > a bug that HPET is always advertise through ACPI table even when qemu
> > haven't created one. So your description above is not accurate.
> 
> I apologize for the confusion.  However, I feel this only furthers my
> proposal.  (There was a defect in hpet table generation - seabios
> knows/cares nothing about the hpet - but now we need to review, patch,
> and coordinate two different projects.)
> 
Seabios "knows/cares nothing about the hpet" is just another
bug/missing features. See hpet spec at www.intel.com/hardwaredesign/hpetspec_1.pdf 
and search for System BIOS (System BIOS need to do this, System BIOS need
to mark that).

> > But even if it was accurate propagation features through software stack is
> > common operation everywhere. Think about adding system call to the
> > kernel and updating libc, or adding feature to kvm kernel module and
> > adding patch to use it in qemu.
> 
> I don't see why the above would deter us from optimizing seabios/qemu
> maintenance work.

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.

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.

> 
> > > 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.
> > > 
> > Then qemu will have to create ACPI header too and will have to fill
> > details like oem_id/oem_table_id and so on. Now if I want to change them
> > in my bios version it is not enough to edit CONFIG_APPNAME in seabios.
> 
> Easily solved - if there exists a table via
> qemu_cfg_acpi_additional_tables(), then SeaBIOS could use the oem_ids
> from that table for all tables SeaBIOS creates.
Why create problem to solve them easily later?

> 
> > If seabios will decide to move to more resent version of ACPI spec it
> > will not be able to do so since it will not fully control table creation.
> 
> Well, SeaBIOS already doesn't fully control table creation.
> 
Users are not suppose to abuse ACPI table passing interface. If they do
that and things breaks they should fix them by themselves. If we start
using this interface internally in qemu that's different.

> 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. You don't
changed you HW when you update you BIOS in non virtualized world. You do
change you BIOS with each new HW though.

> 
> 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.

--
			Gleb.