From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
Libvirt <libvir-list@redhat.com>,
"Peter Krempa" <pkrempa@redhat.com>,
"László Érsek" <lersek@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] Configuring pflash devices for OVMF firmware
Date: Fri, 22 Feb 2019 14:28:04 +0100 [thread overview]
Message-ID: <87imxc2brv.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <87ef84xn2w.fsf@dusky.pond.sub.org> (Markus Armbruster's message of "Tue, 19 Feb 2019 08:19:03 +0100")
The other day, I described how my attempt to implement Paolo's
suggestion to add block properties to the machine ran into difficulties.
To recap briefly, creating devices within a machine's .instance_init()
crashes. Turns out device_post_init() calls qdev_get_machine(), which
calls container_get() for QOM path "/machine". Since "/machine" doesn't
exist, yet (we're busy creating it), container_get() "helpfully" creates
it as a new "container" object. Oww. Fortunately, we crash soon after,
when we try to create the real "/machine".
I managed to rejigger global property application code to work without
qdev_get_machine(). Good.
Not so good: QEMU still crashes the same way.
Turns out we *also* call qdev_get_machine() on the first
sysbus_get_default(). We create the main system bus then, and
immediately store it in "/machine/unattached/sysbus". So
container_get() "helpfully" creates first "/machine" and then
"/machine/unattached" for us.
I managed to rejigger that, too. Now my QEMU survives creating a pflash
device in pc_machine_initfn(), and I can add a machine property
"pflash0" with object_property_add_alias(). Good.
Not so good: attempting to set it with -machine pflash0=pflash0 fails
with "Property 'cfi.pflash01.drive' can't find value 'pflash0'".
Turns out we set the machine's properties around line 4250, some 140
lines before we create block backends. Block backend "pflash0" doesn't
exist, yet.
This is madness, but at least it's familiar madness; we've rejiggered
the order of creating stuff in main() numerous times already.
To be continued...
next prev parent reply other threads:[~2019-02-22 13:28 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-25 15:03 [Qemu-devel] Configuring pflash devices for OVMF firmware Markus Armbruster
2019-01-28 7:58 ` Laszlo Ersek
2019-01-28 10:39 ` Peter Maydell
2019-01-28 12:40 ` [Qemu-devel] [libvirt] " Gerd Hoffmann
2019-01-28 13:06 ` Peter Maydell
2019-01-28 14:55 ` Laszlo Ersek
2019-01-28 14:58 ` Peter Maydell
2019-01-28 15:03 ` Laszlo Ersek
2019-01-30 7:36 ` Markus Armbruster
2019-01-30 8:00 ` Gerd Hoffmann
2019-01-30 7:24 ` [Qemu-devel] " Markus Armbruster
2019-01-30 15:24 ` Peter Maydell
2019-01-30 16:44 ` Laszlo Ersek
2019-01-30 17:24 ` Peter Maydell
2019-01-31 8:52 ` Markus Armbruster
2019-01-31 10:01 ` Peter Maydell
2019-01-31 10:24 ` Markus Armbruster
2019-01-31 10:34 ` Peter Maydell
2019-01-31 12:05 ` Markus Armbruster
2019-01-30 14:13 ` Markus Armbruster
2019-01-30 14:33 ` Paolo Bonzini
2019-01-30 16:38 ` Laszlo Ersek
2019-01-31 8:33 ` Markus Armbruster
2019-01-31 9:19 ` Paolo Bonzini
2019-01-31 9:37 ` Markus Armbruster
2019-01-31 12:02 ` Laszlo Ersek
2019-01-31 12:10 ` Paolo Bonzini
2019-01-31 12:51 ` Markus Armbruster
2019-01-31 8:40 ` Markus Armbruster
2019-01-31 9:19 ` Paolo Bonzini
2019-01-31 9:41 ` Markus Armbruster
2019-01-31 10:12 ` Paolo Bonzini
2019-01-31 12:12 ` Markus Armbruster
2019-01-31 22:57 ` Paolo Bonzini
2019-01-31 23:28 ` Alexandro Sanchez Bach
2019-01-31 23:54 ` Paolo Bonzini
2019-02-01 2:49 ` Ning, Yu
2019-02-04 10:00 ` Paolo Bonzini
2019-02-01 8:58 ` Markus Armbruster
2019-01-31 11:57 ` Laszlo Ersek
2019-02-19 7:19 ` Markus Armbruster
2019-02-22 13:28 ` Markus Armbruster [this message]
2019-02-07 9:30 ` Markus Armbruster
2019-02-07 12:31 ` Laszlo Ersek
2019-02-07 13:49 ` Markus Armbruster
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=87imxc2brv.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=lersek@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@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.