From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml1te-00050I-LA for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:42:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml1tZ-0004uf-It for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:42:13 -0400 Received: from [199.232.76.173] (port=56487 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml1tZ-0004uZ-DY for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:42:09 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24106) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml1tY-0006cP-OO for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:42:09 -0400 Message-ID: <4AA66CCF.3040302@siemens.com> Date: Tue, 08 Sep 2009 16:40:15 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1252401463-3249-1-git-send-email-kraxel@redhat.com> <4AA6607C.4050505@siemens.com> <4AA668A2.1080801@redhat.com> In-Reply-To: <4AA668A2.1080801@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: libvir-list@redhat.com, "qemu-devel@nongnu.org" Gerd Hoffmann wrote: > On 09/08/09 15:47, Jan Kiszka wrote: > >> 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. > > Disk numbers are bad. Define "second hard disk". Especially for a > system with different kinds of disks (say one scsi and one virtio). One could use the specification order, but I agree it's not very handy. > > Drives have names though which can be used to reference the disks, so we > could use that instead. -boot cmd line syntax becomes a bit tricky then > though, we somehow have to figure whenever the user gave us names or > old-style letters. Something like this ... > > -drive if=virtio,id=sys,file=/path/to/disk.img > -cdrom /path/to/install.iso > -boot order=[sys],once=d,menu=off Yes, this looks powerful and clean. One could even still define probe orders like "-boot order=[sys][backup]d". > > ... might work out nicely. I suspect the libvirt folks will hate us for > that though. Does anyone from libvirt want to comment on this? > >> - 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? > > Well. There are quite a few. bochs pcbios, seabios, coreboot ... Ok, but that's only an argument to have extboot as a workaround for bioses not yet supporting scsi and virtio natively, isn't it? I'm thinking long-term here, not arguing against a extboot-based short-term solution. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux