From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36288 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5OOw-0004kT-G7 for qemu-devel@nongnu.org; Mon, 11 Oct 2010 15:51:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5OOv-0001mu-5K for qemu-devel@nongnu.org; Mon, 11 Oct 2010 15:51:14 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:33485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5OOv-0001mm-2y for qemu-devel@nongnu.org; Mon, 11 Oct 2010 15:51:13 -0400 Received: by qyk1 with SMTP id 1so4005308qyk.4 for ; Mon, 11 Oct 2010 12:51:12 -0700 (PDT) Message-ID: <4CB36AAD.7030101@codemonkey.ws> Date: Mon, 11 Oct 2010 14:51:09 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Passing boot order from qemu to seabios References: <20101011101855.GA25030@redhat.com> <4CB2E7D0.1010702@redhat.com> <4CB2FDF2.1020705@redhat.com> In-Reply-To: <4CB2FDF2.1020705@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Kevin Wolf , seabios@seabios.org, qemu-devel@nongnu.org, Gleb Natapov On 10/11/2010 07:07 AM, Gerd Hoffmann wrote: > Hi, > >> Floppy? Yes, I think we do. > > And *one* floppy controllers can actually have *two* drives connected, > although booting from 'b' doesn't work IIRC. > >>> and since one PCI device may >>> control more then one disk (ATA slave/master, SCSI LUNs). We can do >>> what >>> EDD specification does. Describe disk as: >>> bus type (isa/pci), >>> address on a bus (16 bit base address for isa, b/s/f for pci) >>> device type (ATA/SCSI/VIRTIO) >>> device path (slave/master for ATA, LUN for SCSI, nothing for >>> virtio) >> >> If we had a qdev ID for all devices (which I think we should have >> anyway), would this work or is a string not really handy enough? > > I think we'll need support for that in all drivers supporting boot > anyway, i.e. have virtio-blk-pci register a boot edd when configured > that way. Question is how to configure this. We could attach the > boot index to either the blockdev or the device, i.e. > > -blockdev foo,bootindex=1 > > or > > -device virtio-blk-pci,bootindex=1 > > The latter looks more useful to me, boot order is guest state imho, > also it might expand to PXE booting nicely, i.e. > > -device e1000,bootindex=2 > > Which turns up the question how this plays with option roms. seabios > should be able to order at pci device level at least when booting via > (pci) option rom. OK for nics. Booting from a scsi disk with id != 0 > using the lsi rom is probably impossible though. > > What about non-pci option roms? The one used for -kernel for example? -kernel hijacks int19 so it cannot participate in any kind of boot order. It's either present (and therefore the bootable disk) or not present. Regards, Anthony Liguori > cheers, > Gerd >