From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJk5X-0000c6-W9 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 07:59:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJk5W-0002EQ-Tj for qemu-devel@nongnu.org; Thu, 04 Oct 2012 07:59:35 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:36045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJk5W-0002D7-C8 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 07:59:34 -0400 Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 4 Oct 2012 21:56:49 +1000 Message-ID: <506D7A13.9040706@linux.vnet.ibm.com> Date: Thu, 04 Oct 2012 17:29:15 +0530 From: Avik Sil MIME-Version: 1.0 References: <50641A82.4030708@linux.vnet.ibm.com> <1348738150.24701.21.camel@pasglop> <20120927095136.GI23096@redhat.com> <506D6B20.7020508@linux.vnet.ibm.com> <20121004112217.GA27396@redhat.com> <506D7317.40906@linux.vnet.ibm.com> <20121004113206.GA28230@redhat.com> In-Reply-To: <20121004113206.GA28230@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , Alexander Graf , Nikunj A Dadhania , qemu-devel qemu-devel >>>> I looked at the bootindex stuff and found that when the bootindex is >>>> specified for the disk and cdrom it generates a string like: >>>> >>>> "/spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,1 >>>> /spapr-vio-bridge/spapr-vscsi/channel@0/disk@0,0" >>>> >>>> Now converting/translating this to OF device path is going to be >>>> much trickier and might not be proper. So I propose a simple >>>> solution by introducing a global flag that checks if explicit -boot >>>> parameter is provided or not. The presence of this parameter is >>>> verified in SLOF firmware. The flag had to be introduced as >>>> boot_devices defaults to "cad" instead of null and passed to >>>> machine->init(). >>>> >>> So you want to hack around the problem. If -boot is specified what >>> device are you going to boot from? >> >> It is going to boot from the device specified in -boot as >> default_boot_order is set to 0 in that case. >> > -boot has not enough verbosity to tell the device to boot from if you > have more than one device of each type. What are you going to boot from > if you have two disks, two NICs, etc? Yes, -boot has this limitation and -boot is what we are currently using. We are extending this using the nvram boot-device property. With the nvram driver in place, we would be booting from boot-device. We also need a way from qemu to override this, where we hit this issue of the default boot device. And currently SLOF boots from the first disk/cdrom it discovers in device tree in case there are multiple disks or cdroms. Regards, Avik > > -- > Gleb. > > >