From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUKuN-0000nw-Um for qemu-devel@nongnu.org; Tue, 03 Feb 2009 08:01:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUKuJ-0000m0-26 for qemu-devel@nongnu.org; Tue, 03 Feb 2009 08:01:43 -0500 Received: from [199.232.76.173] (port=57207 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUKuI-0000lm-2K for qemu-devel@nongnu.org; Tue, 03 Feb 2009 08:01:38 -0500 Received: from mx20.gnu.org ([199.232.41.8]:24357) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LUKuH-0003Yq-Dk for qemu-devel@nongnu.org; Tue, 03 Feb 2009 08:01:37 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUKuF-00021b-25 for qemu-devel@nongnu.org; Tue, 03 Feb 2009 08:01:35 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Add multi-boot kernel loading support Date: Tue, 3 Feb 2009 13:01:31 +0000 References: <49873680.2040603@exactcode.de> In-Reply-To: <49873680.2040603@exactcode.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902031301.32385.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Rene Rebe , Alexander Graf On Monday 02 February 2009, Rene Rebe wrote: > Hi all, > > Alexander Graf implemented multi-boot kernel loading during > his work to run Darwin inside Qemu/KVM. As the boot loader > expects to load the kernel in an EFI environment a custom > booter is used to load the kernel using a legacy BIOS. > > This is a port of the patch to the new extload / INT 19 > machinery (including minor cleanups). This is introducing quite a lot of nontrivial target code in a hard to understand and maintain way. This seems like a bad idea. I suspect it would be better to implement this as an actual boot rom, and have it read arguments from the firmware device. Ideally the same rom would also cover the linux kernel case. Paul