From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MuX5a-0007F1-39 for qemu-devel@nongnu.org; Sun, 04 Oct 2009 15:49:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MuX5V-0007AJ-G6 for qemu-devel@nongnu.org; Sun, 04 Oct 2009 15:49:49 -0400 Received: from [199.232.76.173] (port=59721 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MuX5V-0007A2-3e for qemu-devel@nongnu.org; Sun, 04 Oct 2009 15:49:45 -0400 Received: from ra.coresystems.de ([80.81.252.129]:38196) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MuX5U-0001uV-IY for qemu-devel@nongnu.org; Sun, 04 Oct 2009 15:49:44 -0400 Subject: Re: [coreboot] [Qemu-devel] Release plan for 0.12.0 From: Patrick Georgi In-Reply-To: <4AC8F80C.2050702@us.ibm.com> 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> Content-Type: text/plain Date: Sun, 04 Oct 2009 21:49:19 +0200 Message-Id: <1254685759.4077.104.camel@tetris> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Coreboot , stepan@coresystems.de, Carl-Daniel Hailfinger , qemu-devel@nongnu.org, ron minnich , Jordan Justen 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. Look at OpenFirmware, the drivers initialize the hardware and provide just enough support to be able to start an operating system, but as soon as the operating system runs, it takes over as much as possible, as quickly as possible. For good reasons, as external drivers (no matter if OF or EFI) impose the same flaw as ACPI: Hardware state changes outside the control of the operating system. 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. Regards, Patrick Georgi