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

[Gleb Natapov]

On Wed, Jun 16, 2010 at 09:22:09PM -0400, Kevin O'Connor wrote:
> 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
In that case new ACPI would never be adopted. No HW manufacturer would
risk to not be able to run WindowsXP on their HW. Real BIOS may have
config option to choose what ACPI version to use though. We can add this
too.

> 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.)
Why do you think so? But anyway my position is that we need to pass
maximum information from qemu to firmware. On real HW bios knows
everything about underlying hardware.


> 
> > > 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.
That was because qemu was stale project for a couple of years. Now pace of
qemu development is very fast, so the same is required from firmware
too. When qemu development started to accelerate BOCHS bios was
essentially forked to allow for faster development.

> 
> 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.
BOCHS bios didn't do it because when qemu development accelerated we
switched to seabios. I agree with paragraph above otherwise. We just not
agree in what form information should be passed. You think we should
pass HPET ACPI table (my guess is just because we already have a way to
pass ACPI table to seabios) and I think this is abuse of ACPI spec. fw cfg
interface was designed to be extendible, why oppose adding things to it?
It is not like if we build HPET table in qemu we will not have to patch
seabios and coordinate changes. Seabios creates HPET table
unconditionally now and we will have to fix it to not do that if HPET
table is passed from qemu (and for that seabios will have to expect all tables
that it receives over fw cfg interface, something it doesn't do now) and
it will have to detect old qemu somehow and create HPET unconditionally
to preserve old behaviour on old qemus. In the end the change to seabios
will be bigger that proposed patch.

> 
> I do view SeaBIOS as primarily a legacy bios interface and a boot
> loader.  
This is worrying statement for qemu project.

>          I also think it makes sense to handle qemu and kvm firmware
> needs - 
Good, but qemu needs are growing in the pace of qemu development and
this is fast these days.

>          some initialization wants to be done from the guest and
> seabios is a good place to do that.
> 
HW does not initialize itself. So the only sane place to do _all_
initialization is from guest.

> 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.
Because OS does not talk directly to qemu. It has mediator in the form
of seabios. We have spec that define interface between seabios and an OS
(ACPI spec) and we define interface between seabios and qemu by ourselves.
Why intentionally blur this separation?

> 
> 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?
> 
I dismissed it (very quickly) on the premiss that this is layering
violation. I saw that I need to specify value that qemu should have
nothing to do with to build header and to support old qemu with new
seabios I need to add new fw cfg key anyway.

--
                        Gleb.