From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MunHo-0003V5-VJ for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:07:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MunHj-0003Ri-HA for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:07:31 -0400 Received: from [199.232.76.173] (port=56790 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MunHj-0003Ra-1a for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:07:27 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:58427) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MunHi-0001Cf-JM for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:07:26 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n95D2oqm003692 for ; Mon, 5 Oct 2009 07:02:50 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n95D7GSA188146 for ; Mon, 5 Oct 2009 07:07:21 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n95D7Fau012809 for ; Mon, 5 Oct 2009 07:07:16 -0600 Message-ID: <4AC9EF82.3050303@us.ibm.com> Date: Mon, 05 Oct 2009 08:07:14 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0 References: <4AC51DBA.7020609@codemonkey.ws> <4AC60037.6000001@codemonkey.ws> <2a50f7880910020958g3fe5eadehe5e5094c05b218d9@mail.gmail.com> <4AC64A5C.6010003@gmx.net> <4AC64C32.4020509@codemonkey.ws> <4AC67326.6080603@gmx.net> <2a50f7880910021528v742c39e8sd334b318c577fb71@mail.gmail.com> <4AC6872E.6060103@gmx.net> <2a50f7880910021732k68ae1a97qc7307ac52a225371@mail.gmail.com> <20091003173006.595.qmail@stuge.se> <2a50f7880910031449k13090dcdr8440d89ccb7fcfe9@mail.gmail.com> <1254607096.12717.10.camel@tetris> <4AC8F80C.2050702@us.ibm.com> <1254685759.4077.104.camel@tetris> In-Reply-To: <1254685759.4077.104.camel@tetris> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Patrick Georgi Cc: Coreboot , stepan@coresystems.de, Carl-Daniel Hailfinger , qemu-devel@nongnu.org, ron minnich , Jordan Justen Patrick Georgi wrote: > Am Sonntag, den 04.10.2009, 14:31 -0500 schrieb Anthony Liguori: > >> I don't know enough about EFI, but my concern is that down the road, >> hardware devices will start to exist that require EFI because they >> implement EFI modules and not legacy option ROMs. In order to support >> PCI passthrough of such devices, we will need to provide an EFI capable >> firmware. >> > Why? They're initialized at boot time (by the host's EFI firmware, if > necessary), and are usable by the OS then. > EFI defines new interfaces for OSes to use. A device is going to want to provide drivers for those new interfaces. For instance, EFI defines a SCSI passthrough protocol such that a RAID controller could install an EFI SCSI driver and that would allow OSes to install to it without requiring special drivers. Of course, I'm sure we'll still see special drivers. I assume that future RAID controllers will provide both a legacy option ROM (int13 hook) and an EFI SCSI driver. However, I'm also pretty sure that we'll see some subset of devices that only provide the EFI modules because they target a very specific class of hardware/software that will be EFI enabled. > Beyond boot loaders and toy kernels, firmware level drivers hurt more > than they help. The world changed since the invention of BIOS in CP/M. > Except that VESA and VGA are still pretty popular. It's not at all uncommon to either use a VESA driver or at least to complete an install with just a VESA driver. -- Regards, Anthony Liguori