From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57020 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5KrV-0006J3-3o for qemu-devel@nongnu.org; Mon, 11 Oct 2010 12:04:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5KrP-0001sU-UF for qemu-devel@nongnu.org; Mon, 11 Oct 2010 12:04:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5KrP-0001sM-O5 for qemu-devel@nongnu.org; Mon, 11 Oct 2010 12:04:23 -0400 Date: Mon, 11 Oct 2010 18:04:19 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios Message-ID: <20101011160419.GG28008@redhat.com> References: <20101011101855.GA25030@redhat.com> <4CB2F1F0.9010404@nsn.com> <20101011142914.GD28008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Bernhard Kohl , seabios@seabios.org, qemu-devel@nongnu.org On Mon, Oct 11, 2010 at 04:52:31PM +0100, Stefan Hajnoczi wrote: > 2010/10/11 Gleb Natapov : > > On Mon, Oct 11, 2010 at 01:48:09PM +0100, Stefan Hajnoczi wrote: > >> On Mon, Oct 11, 2010 at 12:16 PM, Bernhard Kohl wrote: > >> > Am 11.10.2010 12:18, schrieb ext Gleb Natapov: > >> >> > >> >> Currently if VM is started with multiple disks it is almost impossi= ble to > >> >> guess which one of them will be used as boot device especially if t= here > >> >> is a mix of ATA/virtio/SCSI devices. Essentially BIOS decides the o= rder > >> >> and without looking into the code you can't tell what the order will > >> >> be (and in qemu-kvm if boot=3Don is used it brings even more havoc)= =2E We > >> >> should allow fine-grained control of boot order from qemu command l= ine, > >> >> or as a minimum control what device will be used for booting. > >> >> > >> >> To do that along with inventing syntax to specify boot order on qemu > >> >> command line we need to communicate boot order to seabios via fw_cfg > >> >> interface. For that we need to have a way to unambiguously specify a > >> >> disk from qemu to seabios. =9APCI bus address is not enough since n= ot all > >> >> devices are PCI (do we care about them?) and since one PCI device m= ay > >> >> control more then one disk (ATA slave/master, SCSI LUNs). We can do= what > >> >> EDD specification does. Describe disk as: > >> >> =9A =9A bus type (isa/pci), > >> >> =9A =9A address on a bus (16 bit base address for isa, b/s/f for pc= i) > >> >> =9A =9A device type (ATA/SCSI/VIRTIO) > >> >> =9A =9A device path (slave/master for ATA, LUN for SCSI, nothing fo= r virtio) > >> >> > >> >> Will it cover all use cased? Any other ideas? > >> > > >> > I think this also applies to network booting via gPXE. Usually our V= Ms > >> > have 4 NICs, mixed virtio-net and PCI pass-through. 2 of the NICs sh= all > >> > be used for booting, even if there are hard disks or floppy disks > >> > connected. This scenario is currently almost impossible to configure. > >> > >> Here is a gPXE to support fw_cfg. =9AYou can pass gPXE script files fr= om > >> the host to gPXE inside the guest. =9AThis means you can boot specific > >> NICs: > >> http://patchwork.ozlabs.org/patch/43777/ > >> > >> Just wanted to post the link because it is related to the gPXE side of > >> this discussion. > >> > > Don't we load gPXE for each NIC and seabios passes PCI device to boot f= rom > > when it invokes one of them? >=20 > SeaBIOS may do that but gPXE internally just probes all PCI devices. > It does not take advantage of the PCI bus/addr/fn that was passed to > the option ROM. A gPXE instance will try booting from each available > NIC in sequence. Ah, thanks for clarification. Looks like gPXE does the wrong thing here. Can this behaviour be changed by compile time option? -- Gleb.