From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy8L2-0004Ya-7m for qemu-devel@nongnu.org; Mon, 08 Dec 2014 19:07:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xy8Ku-0000wy-Tv for qemu-devel@nongnu.org; Mon, 08 Dec 2014 19:07:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy8Ku-0000vE-3j for qemu-devel@nongnu.org; Mon, 08 Dec 2014 19:07:28 -0500 Message-ID: <54863D38.2070906@redhat.com> Date: Tue, 09 Dec 2014 01:07:20 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1417804575-19329-1-git-send-email-lersek@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/3] hw/arm/virt: boot with -kernel -initrd -append on top of UEFI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Wei Huang , Drew Jones , Ard Biesheuvel , qemu devel list "Richard W.M. Jones" , Cole Robinson On 12/05/14 19:55, Peter Maydell wrote: > On 5 December 2014 at 18:36, Laszlo Ersek wrote: >> A number of tools depend on passing the kernel image, the initial >> ramdisk, and the kernel command line to the guest on the QEMU command >> line (options -kernel, -initrd, -append, respectively). At the moment, >> these QEMU options work, but the guest kernel loaded this way is >> launched by a minimal binary firmware that is dynamically composed by >> QEMU. As a consequence, such a kernel has no UEFI environment. >> >> In this patchset the kernel, initrd and cmdline blobs are passed to the >> guest firmware to process & load. This mode is activated when both >> -kernel and -pflash unit#0 (or -bios) are specified. > > ...so we avoid back-compat problems on the assumption that > nobody was previously trying to provide both -bios and > -kernel at once. I *think* that's probably a reasonable > assumption... I'm including these three too in the new patchset that I'll post soon, so no need to keep these queued. Thanks Laszlo