On Fri, 05 Oct 2012 09:25:25 -0500, Anthony Liguori <aligu...@us.ibm.com> wrote: > 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.
Yes, and thats where the problem lies, when -boot is not included. Qemu assumes "cad" and sends it down to the firmware. Then we do not know that -boot is provided or not. Regards Nikunj
