From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJkhb-0000Ji-Qy for qemu-devel@nongnu.org; Thu, 04 Oct 2012 08:39:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJkhX-0008Ak-98 for qemu-devel@nongnu.org; Thu, 04 Oct 2012 08:38:55 -0400 Date: Thu, 4 Oct 2012 14:38:24 +0200 From: Gleb Natapov Message-ID: <20121004123824.GA30164@redhat.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D3A912F-CB8F-450E-87B3-4E3C4D32B020@suse.de> 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 Cc: Benjamin Herrenschmidt , "qemu-ppc@nongnu.org List" , Avik Sil , Nikunj A Dadhania , qemu-devel qemu-devel On Thu, Oct 04, 2012 at 02:37:22PM +0200, Alexander Graf wrote: > > On 04.10.2012, at 14:35, Avik Sil wrote: > > >>>>>> 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. > >>>> > >>>> 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. > +1 -- Gleb.