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