From: Gleb Natapov <gleb@redhat.com>
To: Benjamin Herrenschmidt <benh@au1.ibm.com>
Cc: Avik Sil <aviksil@linux.vnet.ibm.com>,
"qemu-ppc@nongnu.org List" <qemu-ppc@nongnu.org>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>,
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting
Date: Thu, 27 Sep 2012 12:35:00 +0200 [thread overview]
Message-ID: <20120927103500.GM23096@redhat.com> (raw)
In-Reply-To: <1348741303.24701.29.camel@pasglop>
On Thu, Sep 27, 2012 at 08:21:43PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-09-27 at 11:51 +0200, Gleb Natapov wrote:
>
> > Yes, forget about -boot. It is deprecated :) You should use bootindex
> > (device property) to set boot priority. It constructs OF device path
> > and passes it to firmware. There is nothing "blurry" about OF device
> > path.
>
> Of course it is ;-) They are perfectly precise down to the device for
> which qemu generates the device-tree ... and from there it requires the
> firmware and qemu to both agree on how they are constructed, and it
> becomes totally unpredictable once things like f-code drivers coming
> from adapter ROMs enter the picture.
>
If QEMU generates OF device path that can't be used by firmware uniquely
identify the device this is QEMU bug. You are correct about ROMs though.
At least on a PC single ROM can register multiple boot vectors and since
QEMU knows nothing about them it can't prioritize between them. It's sad
if OF has similar problem.
> In fact, we can probably get them right down the the PCI device for PCI
> (for which we don't currently construct the device nodes in qemu, but we
> can 'guess'). And we can probably get the right unit address for vscsi,
> virtio-scsi, etc... but that's about it.
What more do you need?
>
> > The problem is that it works reasonably well with legacy BIOS
> > since it is enough to specify device to boot from, but with EFI (OF is
> > the same I guess) it is not enough to point to a device to boot from,
> > but you also need to specify a file you want to boot and this is where
> > bootindex approach fails. If EFI would specify default file to boot from
> > firmware could have used it, but EFI specifies it only for removable media
> > (what media is not removable this days, especially with virtualization?).
> > We can add qemu parameter to specify file to boot, but how users should
> > know the name of the file?
>
> Cheers,
> Ben.
>
>
--
Gleb.
next prev parent reply other threads:[~2012-09-27 10:37 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50641A82.4030708@linux.vnet.ibm.com>
[not found] ` <1348738150.24701.21.camel@pasglop>
2012-09-27 9:33 ` [Qemu-devel] [Qemu-ppc] Qemu boot device precedence over nvram boot-device setting Alexander Graf
2012-09-27 9:35 ` Benjamin Herrenschmidt
2012-09-27 9:39 ` Alexander Graf
2012-09-27 9:51 ` Gleb Natapov
2012-09-27 10:05 ` Nikunj A Dadhania
2012-09-27 10:13 ` Gleb Natapov
2012-09-27 10:34 ` Nikunj A Dadhania
2012-09-27 10:38 ` Gleb Natapov
2012-09-27 10:21 ` Benjamin Herrenschmidt
2012-09-27 10:35 ` Gleb Natapov [this message]
2012-09-28 6:12 ` Jordan Justen
2012-10-04 10:55 ` Avik Sil
2012-10-04 11:22 ` Gleb Natapov
2012-10-04 11:29 ` Avik Sil
2012-10-04 11:30 ` Alexander Graf
2012-10-04 12:18 ` Avik Sil
2012-10-04 12:21 ` Alexander Graf
2012-10-04 12:35 ` Avik Sil
2012-10-04 12:37 ` Alexander Graf
2012-10-04 12:38 ` Gleb Natapov
2012-10-05 4:45 ` Nikunj A Dadhania
2012-10-04 11:32 ` Gleb Natapov
2012-10-04 11:59 ` Avik Sil
2012-10-05 0:34 ` David Gibson
2012-10-05 0:43 ` Alexander Graf
2012-10-05 0:48 ` David Gibson
2012-10-05 9:12 ` Benjamin Herrenschmidt
2012-10-05 10:32 ` Alexander Graf
2012-10-05 5:30 ` Nikunj A Dadhania
2012-10-05 5:44 ` Avik Sil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120927103500.GM23096@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=aviksil@linux.vnet.ibm.com \
--cc=benh@au1.ibm.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.