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

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

[Alexander Graf]

On 05.10.2012, at 16:00, Avik Sil <aviksil@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 <agraf@suse.de> wrote:
>>>> 
>>>> 
>>>> On 05.10.2012, at 10:29, Avik Sil <aviksil@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.

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

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

[Anthony Liguori]

Alexander Graf <agraf@suse.de> writes:

> On 05.10.2012, at 16:00, Avik Sil <aviksil@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 <agraf@suse.de> wrote:
>>>>> 
>>>>> 
>>>>> On 05.10.2012, at 10:29, Avik Sil <aviksil@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
>> 
>> 

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 <aliguori@us.ibm.com> wrote:

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

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

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

[Nikunj A Dadhania]

On Fri, 05 Oct 2012 09:25:25 -0500, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Alexander Graf <agraf@suse.de> writes:
> 
> > On 05.10.2012, at 16:00, Avik Sil <aviksil@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 <agraf@suse.de> wrote:
> >>>>> 
> >>>>> 
> >>>>> On 05.10.2012, at 10:29, Avik Sil <aviksil@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