From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml187-0001Mv-OP for qemu-devel@nongnu.org; Tue, 08 Sep 2009 09:53:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml183-0001HU-4V for qemu-devel@nongnu.org; Tue, 08 Sep 2009 09:53:07 -0400 Received: from [199.232.76.173] (port=40628 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml182-0001HK-T1 for qemu-devel@nongnu.org; Tue, 08 Sep 2009 09:53:02 -0400 Received: from goliath.siemens.de ([192.35.17.28]:20261) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml182-00062A-8L for qemu-devel@nongnu.org; Tue, 08 Sep 2009 09:53:02 -0400 Message-ID: <4AA6607C.4050505@siemens.com> Date: Tue, 08 Sep 2009 15:47:40 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1252401463-3249-1-git-send-email-kraxel@redhat.com> In-Reply-To: <1252401463-3249-1-git-send-email-kraxel@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Gerd Hoffmann wrote: > $subject says pretty much everything. > > extboot.[cS] are a straight copy from the kvm tree. The windup in vl,c > and hw/pc.c is done slightly different, I've added a function to lookup > the boot drive instead of adding a new global variable. > > Booting from scsi and virtio works, using the boot=on flag. > > With the usb+scsi patches in anthonys patch queue applied booting from > usb works too. Syntax is this: > > -drive if=none,id=pendrive,file=/path/to/image,boot=on > -usb -device usb-storage,drive=pendrive > > Booting a rawhide install from a virtual usb stick doesn't actually work > though, looks like it stresses qemus usb emulation too much. > Before setting this definitely useful feature in stone, I have two questions though: - -drive ...,boot=on is logically in conflict with -boot. Yes, -boot for x86 currently cannot differentiate between multiple disks, only between boot media types. Still, this two-stage configuration is rather unintuitive and looks like a patchwork. Given that we have full control over all components, is it really the preferred approach? I already thought about, e.g., -boot c2 to select the second disk. Not that nice, but I would rather vote for a consistent configuration than a scattered one. - This is just an implementation detail: Do we really need to implement booting from virtio and scsi via an extension rom? Isn't it possible to merge the corresponding support into the main bios? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux