qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] unique (or otherwise) RAM block names


From: Laszlo Ersek
Subject: Re: [Qemu-devel] unique (or otherwise) RAM block names
Date: Mon, 4 Jun 2018 14:48:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 06/01/18 19:34, Peter Maydell 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.
> 
> 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.)

Related: commit f58b39d2d5b6 ("virtio-mmio: format transport base
address in BusClass.get_dev_path", 2016-07-14).

Thanks
Laszlo



reply via email to

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