From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml4Fl-0003is-TT for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:13:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml4Fh-0003Va-8N for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:13:13 -0400 Received: from [199.232.76.173] (port=55928 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml4Fh-0003VH-4T for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:13:09 -0400 Received: from mx20.gnu.org ([199.232.41.8]:33102) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml4Fg-0002SP-SE for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:13:08 -0400 Received: from qw-out-1920.google.com ([74.125.92.146]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ml4Fg-0003Dp-9E for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:13:08 -0400 Received: by qw-out-1920.google.com with SMTP id 5so798225qwc.4 for ; Tue, 08 Sep 2009 10:13:06 -0700 (PDT) Message-ID: <4AA69095.5070200@codemonkey.ws> Date: Tue, 08 Sep 2009 12:12:53 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm 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> <4AA6831F.6070501@siemens.com> In-Reply-To: <4AA6831F.6070501@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "libvir-list@redhat.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" Jan Kiszka wrote: >>>>> - 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). > What we won't need long term is the extboot interface (hw/extboot.c). Ideally, we would rewrite the extboot option rom to have a proper virtio-blk driver in it. Better yet, to finish up Laurent's work of adding virtio-blk support to gpxe since it gives us bcv for free. We woudl then support booting from multiple disks by specifying the bcv entry index in cmos. Then we would need a new syntax for boot (like -boot c3 to chose the 3rd disk device). Regards, Anthony Liguori > Jan > >