From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ml23y-0004oN-0i
	for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:52:54 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ml23t-0004nn-DG
	for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:52:53 -0400
Received: from [199.232.76.173] (port=34814 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ml23t-0004nk-8k
	for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:52:49 -0400
Received: from mx1.redhat.com ([209.132.183.28]:29108)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1Ml23s-0000wv-QN
	for qemu-devel@nongnu.org; Tue, 08 Sep 2009 10:52:49 -0400
Message-ID: <4AA66FBC.5080502@redhat.com>
Date: Tue, 08 Sep 2009 16:52:44 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
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>
In-Reply-To: <4AA66CCF.3040302@siemens.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: libvir-list@redhat.com, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

>>     -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 ...

>>>    - 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.

cheers,
   Gerd