From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml3M6-0004CK-Ji for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml3M1-0004AB-M1 for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:42 -0400 Received: from [199.232.76.173] (port=46566 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml3M1-00049y-Bq for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:37 -0400 Received: from goliath.siemens.de ([192.35.17.28]:21392) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml3Lw-0003pN-Sv for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:33 -0400 Message-ID: <4AA6831F.6070501@siemens.com> Date: Tue, 08 Sep 2009 18:15:27 +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> <4AA66CCF.3040302@siemens.com> <4AA66FBC.5080502@redhat.com> In-Reply-To: <4AA66FBC.5080502@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: >>> -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". > > Well, except that boot orders with two hard drives in there don't work > in the PC world ... That depends on your bios. I've seen many that allow disk boot ordering, though they may not support "[sys]d[backup]". However, I see no technical reason for artificially restricting qemu bios capabilities. > >>>> - 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. > > I think it would be useful. Adding a fw_cfg knob to signal 'please boot > via extboot protocol instead of ide disk' should be enougth to allow > bioses supporting extboot directly. Additional plus is we can probably > code it in C not asm then. I'm still not convinced we need extboot for all bioses on the long term. And I think we should define new interfaces in a way that finally makes it obsolete, at least for our "home bios" (whatever it will be). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux