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: Nikunj A Dadhania
Subject: Re: [Qemu-ppc] [PATCH] Workaround to bypass default qemu boot devices passed to SLOF
Date: Fri, 05 Oct 2012 23:23:13 +0530
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/24.0.95.1 (x86_64-redhat-linux-gnu)

On Fri, 5 Oct 2012 14:09:15 +0200, Alexander Graf <address@hidden> 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.

At the moment, slof does not look at bootindex. That can be sorted out
at a later point of time.
 
> > 
> >> 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".

I like this idea, hoping that it does not break anything.

Regards
Nikunj




reply via email to

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