qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH] Workaround to bypass default qemu boot devices pa


From: Alexander Graf
Subject: Re: [Qemu-ppc] [PATCH] Workaround to bypass default qemu boot devices passed to SLOF
Date: Fri, 5 Oct 2012 16:13:20 +0200


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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]