From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] unique (or otherwise) RAM block names
Date: Fri, 1 Jun 2018 18:42:43 +0100 [thread overview]
Message-ID: <20180601174242.GD2531@work-vm> (raw)
In-Reply-To: <CAFEAcA8Khsu3HTPbsJW-gBvbzrzJkb=z3tpmELwGyw3rQObJFA@mail.gmail.com>
* Peter Maydell (peter.maydell@linaro.org) wrote:
> I was going through trying to fix up various devices that currently
> fail to register RAM blocks for migration, or register the RAM
> block globally rather than locally, and I ran into something
> unexpected.
>
> We name RAM blocks in qemu_ram_set_idstr() like this:
> * if the user passed a device pointer, then call qdev_get_dev_path(),
> and if that returns non-NULL, use "path/name"
> * otherwise, use "name"
>
> Unfortunately, it turns out that there's no guarantee that
> qdev_get_dev_path() will return anything useful. If the device
> isn't on a bus, or the bus's class doesn't implement the get_dev_path
> method, then it'll return NULL.
>
> In particular, this means that if you create what you expect to
> be a local-to-this-device RAM memory region in a SysBusDevice,
> then (because SysBus doesn't implement get_dev_path), there is
> no per-device qualification added to the region name, and so the
> code silently creates a globally-namespaced RAM region.
> Trying to create multiple instances of the device therefore fails.
For device we also have a nmumerical 'instance_id' parameter that
some odd setups use.
> How can we make this work (preferably without breaking migration
> compat for existing devices) ?
>
> (Sysbus isn't the only bus that doesn't implement get_dev_path,
> it's just the first one I found.)
My preference would be that for new machine types we should
define get_dev_path on the busses that are missing it.
Dave
> thanks
> -- PMM
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-06-01 17:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 17:34 [Qemu-devel] unique (or otherwise) RAM block names Peter Maydell
2018-06-01 17:42 ` Dr. David Alan Gilbert [this message]
2018-06-04 12:20 ` Peter Maydell
2018-06-04 12:48 ` Laszlo Ersek
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=20180601174242.GD2531@work-vm \
--to=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.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.