From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK8qj-0004I8-Q3 for qemu-devel@nongnu.org; Fri, 05 Oct 2012 10:26:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK8qa-0008TC-1h for qemu-devel@nongnu.org; Fri, 05 Oct 2012 10:25:57 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:41102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK8qZ-0008Sj-Cv for qemu-devel@nongnu.org; Fri, 05 Oct 2012 10:25:47 -0400 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 6 Oct 2012 00:23:34 +1000 From: Anthony Liguori In-Reply-To: References: <1349425748-15721-1-git-send-email-aviksil@linux.vnet.ibm.com> <87391tuowj.fsf@linux.vnet.ibm.com> <506EE7E3.7050009@linux.vnet.ibm.com> Date: Fri, 05 Oct 2012 09:25:25 -0500 Message-ID: <87k3v5gfmy.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] Workaround to bypass default qemu boot devices passed to SLOF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , Avik Sil Cc: "qemu-ppc@nongnu.org" , qemu-devel qemu-devel , Nikunj A Dadhania Alexander Graf writes: > On 05.10.2012, at 16:00, Avik Sil wrote: > >> On 10/05/2012 05:39 PM, Alexander Graf wrote: >>> >>> On 05.10.2012, at 13:41, Nikunj A Dadhania wrote: >>> >>>> On Fri, 5 Oct 2012 12:24:47 +0200, Alexander Graf wrote: >>>>> >>>>> >>>>> On 05.10.2012, at 10:29, Avik Sil wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> Please find below the patch for working around the default boot device issue currently being discussed on the list. >>>>>> >>>>>> Regards, >>>>>> Avik >>>>>> --- >>>>>> >>>>>> The default qemu boot_devices string passed to firmware is "cad" >>>>>> which creates a confusion whether -boot oprion is specified or >>>>>> not. This patch handles this issue by setting a global flag when >>>>>> no -boot option is specified. >>>>> >>>>> Hrm. How does x86 distinguish between -boot and bootindex=? >>>> >>>> IMHO, that behaviour is not changed with this patch. Not sure how >>>> seabios is taking care of this. >>> >>> I don't care about what you change with the patch. I care about consistency. And we shouldn't differ from x86 in that respect. >>> >>> So please try and figure out how x86 knows that bootindex= is supposed to be used instead of -boot. We want the same logic for ppc. >>> >>>> >>>>> Also, we could just map -boot c to "nvram given boot device or first >>>>> automatically found disk". Then there's no need to know whether a >>>>> default was given. If you specify -boot you most likely want to force >>>>> cd-rom or network boot anyway and there is no way to tell which disk >>>>> 'c' would reflect. >>>> >>>> We do want to use -boot [cad], but not for the nvram saved >>>> boot-device. That is done automatically in SLOF. If there is a property >>>> saved named boot-device, its going to use that for booting. >>> >>> Hrm. Ok, how about we change the default string to >>> >>> xcad >>> >>> with x meaning "device stored in nvram". Then any time you specify -boot it would override the nvram device, but you could also manually specify "I want to only boot from the nvram device, no fallbacks". >>> >> Setting default string to "xcad" might jeopardize behavior of other machines (about hundred of them) that are passed boot_devices through machine->init() > > Ugh. I only realized just now that qemu-devel is not CC'ed. > > Let's ask the non-ppc guys what they think. I would really like to > make "boot from nvram default device" just yet another -boot drive > option. That would scale a lot better. The way this works on x86 is that we don't preserve nvram and -boot/bootindex essentially populates it. Semantically, -boot/bootindex ought to override whatever is in nvram. I'm not sure that we want to have two distinct boot mechanism... if you want to boot from the nvram selection, just don't include a -boot option. Regards, Anthony Liguori > > Alex > >>> >>> Alex >>> >>>> The point here is when we really want to over-ride the boot-device >>>> setting in nvram(say the boot-device specified got corrupted), we need >>>> help from -boot and corresponding disk provided in the qemu >>>> command-line. >>>> >>>> At present, if there is boot-device specified there is now way to >>>> over-ride it using qemu command line as "cad" is passed by >>>> default. Which is the cause of all the pain. >>>> >>>> Regards, >>>> Nikunj >>>> >> >> Regards, >> Avik >> >>