From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45305 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOKbV-00084D-3V for qemu-devel@nongnu.org; Mon, 14 Jun 2010 21:06:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOKQW-0001WK-0o for qemu-devel@nongnu.org; Mon, 14 Jun 2010 20:54:53 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:55068) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOKQV-0001WB-Pi for qemu-devel@nongnu.org; Mon, 14 Jun 2010 20:54:51 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCHv2] load hpet info for HPET ACPI table from qemu Date: Tue, 15 Jun 2010 01:54:47 +0100 References: <20100614083053.GC21797@redhat.com> <4C1641EF.9070001@redhat.com> <20100614182521.GA22454@morn.localdomain> In-Reply-To: <20100614182521.GA22454@morn.localdomain> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006150154.47613.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin O'Connor , seabios@seabios.org, Avi Kivity , Gleb Natapov > > >>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 don't think you can draw a clear conclusion one way or the other. ACPI may defined and an API between the firmware and OS, but its primary purpose is to allow the OS to interface with the hardware. While I do think it's desirable to have a single bios image work across the different machines qemu emulates, I don't think it's realistic to develop/release the two independently. The rate of change may be such that we have a fair amount of slack, and it may often be possible to make bios images backwards compatible. However I think it's entirely reasonable to require people use matching bios and qemu. Paul