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