Alexander Graf <ag...@suse.de> writes: > On 05.10.2012, at 16:00, Avik Sil <avik...@linux.vnet.ibm.com> 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 <ag...@suse.de> wrote: >>>>> >>>>> >>>>> On 05.10.2012, at 10:29, Avik Sil <avik...@linux.vnet.ibm.com> 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 >> >>
