On 06/14/2010 01:25 PM, Kevin O'Connor wrote:
On Mon, Jun 14, 2010 at 05:51:27PM +0300, Avi Kivity wrote:
On 06/14/2010 05:09 PM, Gleb Natapov wrote:
Could we just have qemu build the hpet tables and pass them through to seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
Possible, and I considered that. I personally prefer to pass minimum information required for seabios to discover underlying HW and leave ACPI table creation to seabios. That is how things done for HW that seabios can actually detect. If we will go your way pretty soon we will move creation of ACPI/SMBIOS/MP tables into qemu and IMHO this will be step backworkds.
I agree. ACPI is a firmware/OS interface. If we move ACPI table generation into qemu, it becomes a mixed hardware/firmware/OS interface.
This seems to be a philosophical distinction. Lets go over the practical implications.
It seems there was a change in qemu to the hpet functionality. Although the change is solely between qemu and the OS, it's necessary to patch both qemu and seabios for the OS to see the change. This means creating and reviewing patches for two separate repos. This also requires release coordination - the seabios change has to be committed and released, and then qemu needs to be released with the new seabios. Additional changes in seabios tip will get merged into qemu, which could complicate testing.
I think we can be pretty flexible as long as we're careful about releases. For instance, I've applied Gleb's current patch but won't update SeaBIOS until the interface is worked out. If we decide to implement a new interface, there's no harm since we've never had a qemu build that had a combination of SeaBIOS and fw_cfg that didn't work.
Regards,
Anthony Liguori