From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml601-0003nb-7k for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:05:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml5zw-0003lQ-Hy for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:05:04 -0400 Received: from [199.232.76.173] (port=60873 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml5zw-0003lK-Eg for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:05:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55503) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ml5zv-0004jE-SC for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:05:00 -0400 Message-ID: <4AA6AC56.5020700@redhat.com> Date: Tue, 08 Sep 2009 22:11:18 +0300 From: Avi Kivity 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> <4AA66B10.2050901@codemonkey.ws> <4AA680BB.5020201@redhat.com> <4AA692A0.1070006@codemonkey.ws> In-Reply-To: <4AA692A0.1070006@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , Gerd Hoffmann , qemu-devel@nongnu.org On 09/08/2009 08:21 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> On 09/08/2009 05:32 PM, Anthony Liguori wrote: >>> 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 >>> >>> x86 boot is strange. The BIOS boots from the "first hard disk" >>> What extboot allows you do to is redefine to the bios what >>> constitutes the "first hard disk". >> >> It's not just booting - it's the int 0x13 interface. Grub for >> example continues to use it and can boot from the second hard disk if >> desired. > > Our BIOS can only support booting from the 0x80 and this is pretty > normal. The bios exports the "bios drives". You can tell grub to load a kernel from the first partition of the second disk: (hd1,0) or even chain-load another boot loaded from another disk. > > The right way to do this from a BBS perspective would be to implement > BCV support. We could then have BCV entries for every possible disk. > Option roms (like extboot/gpxe) can register add new BCV entries. > We'd want the user to be able to specify the priority of each disk, so.. I don't know anything about BBS/BCV but it seems reasonable. > >> I agree with this and I think we should extend it to >> boot=0x80|0x81.... boot=on is an alias to boot=0x80. > > Would be better to stick with 0-based integers. We would then use > this to generate BCV priorities. Sure. > > The highest priority BCV device is still exposed as int13 disk 0x80. > I suspect certain OSes will only boot from disk 0x80 (probably Windows). Windows has its own boot loader drive format that can specify other drives (I think using its own drivers, not the bios). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.