From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [SeaBIOS] KVM call agenda for 2013-05-28 Date: Thu, 30 May 2013 08:12:25 +0200 Message-ID: <51A6EDC9.6040403@redhat.com> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: KVM devel mailing list , "Michael S. Tsirkin" , seabios@seabios.org, qemu-devel qemu-devel , Juan Quintela , Kevin O'Connor , dwmw2@infradead.org To: Anthony Liguori Return-path: In-Reply-To: <871u8p92v8.fsf@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Hi, >>> Raised >>> that QOM interface should be sufficient. >> >> Agree on this one. Ideally the acpi table generation code should be >> able to gather all information it needs from the qom tree, so it can be >> a standalone C file instead of being scattered over all qemu. > > Ack. So my basic argument is why not expose the QOM interfaces to > firmware and move the generation code there? Seems like it would be > more or less a copy/paste once we had a proper implementation in QEMU. Well, no. Firmware is a quite simple environment without standard libc etc, so moving code from qemu to firmware certainly isn't as easy as copying over a file. >>> There were discussions on potentially introducing a middle component >>> to generate the tables. Coreboot was raised as a possibility, and >>> David thought it would be okay to use coreboot for both OVMF and >>> SeaBIOS. >> >> Certainly an option, but that is a long-term project. > > Out of curiousity, are there other benefits to using coreboot as a core > firmware in QEMU? Short-term it's alot of work as we have to bring coreboot's qemu support to feature parity with seabios. I suspect most of this is acpi related though, so when qemu provides the tables and coreboot uses them we could be pretty close already. Long-term it should simplify firmware maintainance as we have only *one* place which handles the hardware bringup, and seabios/ovmf have less work to do. > Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? I wouldn't be surprised if people start using other coreboot payloads and/or features such as direct linux kernel boot once it works well on qemu. We might even run qemu test suites as coreboot payload. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhw6e-0005xA-4t for qemu-devel@nongnu.org; Thu, 30 May 2013 02:13:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uhw6Z-0002TX-Ht for qemu-devel@nongnu.org; Thu, 30 May 2013 02:13:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhw6Z-0002TS-8D for qemu-devel@nongnu.org; Thu, 30 May 2013 02:12:55 -0400 Message-ID: <51A6EDC9.6040403@redhat.com> Date: Thu, 30 May 2013 08:12:25 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws> In-Reply-To: <871u8p92v8.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: KVM devel mailing list , "Michael S. Tsirkin" , seabios@seabios.org, qemu-devel qemu-devel , Juan Quintela , Kevin O'Connor , dwmw2@infradead.org Hi, >>> Raised >>> that QOM interface should be sufficient. >> >> Agree on this one. Ideally the acpi table generation code should be >> able to gather all information it needs from the qom tree, so it can be >> a standalone C file instead of being scattered over all qemu. > > Ack. So my basic argument is why not expose the QOM interfaces to > firmware and move the generation code there? Seems like it would be > more or less a copy/paste once we had a proper implementation in QEMU. Well, no. Firmware is a quite simple environment without standard libc etc, so moving code from qemu to firmware certainly isn't as easy as copying over a file. >>> There were discussions on potentially introducing a middle component >>> to generate the tables. Coreboot was raised as a possibility, and >>> David thought it would be okay to use coreboot for both OVMF and >>> SeaBIOS. >> >> Certainly an option, but that is a long-term project. > > Out of curiousity, are there other benefits to using coreboot as a core > firmware in QEMU? Short-term it's alot of work as we have to bring coreboot's qemu support to feature parity with seabios. I suspect most of this is acpi related though, so when qemu provides the tables and coreboot uses them we could be pretty close already. Long-term it should simplify firmware maintainance as we have only *one* place which handles the hardware bringup, and seabios/ovmf have less work to do. > Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? I wouldn't be surprised if people start using other coreboot payloads and/or features such as direct linux kernel boot once it works well on qemu. We might even run qemu test suites as coreboot payload. cheers, Gerd