[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [PATCH] Workaround to bypass default qemu bo
From: |
Nikunj A Dadhania |
Subject: |
Re: [Qemu-devel] [Qemu-ppc] [PATCH] Workaround to bypass default qemu boot devices passed to SLOF |
Date: |
Fri, 05 Oct 2012 23:11:11 +0530 |
User-agent: |
Notmuch/0.13.2 (http://notmuchmail.org) Emacs/24.0.95.1 (x86_64-redhat-linux-gnu) |
On Fri, 05 Oct 2012 09:25:25 -0500, 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.
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