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