From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJznt-00084y-50 for qemu-devel@nongnu.org; Fri, 05 Oct 2012 00:46:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJzns-0002uY-1A for qemu-devel@nongnu.org; Fri, 05 Oct 2012 00:46:25 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:35693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJznr-0002uT-Dt for qemu-devel@nongnu.org; Fri, 05 Oct 2012 00:46:23 -0400 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 5 Oct 2012 10:16:15 +0530 From: Nikunj A Dadhania In-Reply-To: <1D3A912F-CB8F-450E-87B3-4E3C4D32B020@suse.de> 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> <49B19A15-2864-4354-BA5E-66CBA139FD84@suse.de> <506D7EA4.6040300@linux.vnet.ibm.com> <751E4F90-614C-41A7-844A-6280BA05345D@suse.de> <506D8283.6090604@linux.vnet.ibm.com> <1D3A912F-CB8F-450E-87B3-4E3C4D32B020@suse.de> Date: Fri, 05 Oct 2012 10:15:35 +0530 Message-ID: <87boghv85s.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain 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: Alexander Graf , Avik Sil Cc: Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , qemu-devel qemu-devel , Gleb Natapov On Thu, 4 Oct 2012 14:37:22 +0200, Alexander Graf wrote: > > >>>> Imagine you have 2 controllers: > >>>> > >>>> * vio > >>>> * virtio > >>>> > >>>> and you specify -boot c. Which device are you going to boot from? > >>> > >>> Currently, by default SLOF boots from the first disk it discovers in the device tree. > >> > >> So you want to replace one broken scheme with another broken scheme? :) > > > > Ha ha, actually we hit this issue in some different context with respect to nvram boot-device which I mentioned in [1]. The patch is a workaround for that issue only. > > Seriously, just ignore -boot for now. It'd be a lot more useful to get bootindex working. I understand your point here. Adding bootindex feature is desirable, I agree to that. While, in the particular use case, we just need to know that -boot was not provided (and some vague default "cad" is provided, which can actually be a user passed parameter as well) and rest can be handled by the firmware. Regards, Nikunj