Re: [Qemu-devel] [Qemu-ppc] [PATCH] Workaround to bypass default qemu boot devices passed to SLOF

[Alexander Graf]

On 05.10.2012, at 16:25, Anthony Liguori <address@hidden> wrote:

> Alexander Graf <address@hidden> writes:
> 
>> On 05.10.2012, at 16:00, Avik Sil <address@hidden> 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 <address@hidden> wrote:
>>>>>> 
>>>>>> 
>>>>>> On 05.10.2012, at 10:29, Avik Sil <address@hidden> 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.

That's exactly my point. With the patch at hand, you get

if (boot_specified) {
  do_boot();
} else {
  do_nvram();
}

While I was suggesting:

do_boot() {
  switch(arg) {
  case 'x':
    do_nvram(); break;
  case 'n':
    do_network(); break;
  ...
  }
}

That way we only have a single place that handles the boot order, not a bunch 
of cluttered if's all over the place.

We could do the same for bootindex. Make bootindex be boot arg 'i' and prepend 
it to the list, before 'x'. That way the default boot order would always be 
dictated by -boot, just that the alternative boot options are subargs of it.

I hope that makes sense,

Alex

> 
> 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
>>> 
>>> 
>