[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RAMBlock's named ""
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] RAMBlock's named "" |
Date: |
Wed, 8 Mar 2017 10:45:07 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
* Igor Mammedov (address@hidden) wrote:
> On Tue, 7 Mar 2017 19:46:56 +0000
> "Dr. David Alan Gilbert" <address@hidden> wrote:
>
> > We seem to have a couple of weird cases where we end up with
> > RAMBlocks with no name; I think they'll badly confuse
> > the migration code, but I don't quite understand how they're
> > happening.
> >
> > 1) device_del e1000e
> > 2) -object memory-backend-file without wiring it up
> >
> > I added some debug into migration/ram.c ram_save_setup to
> > dump the names it was seeing in it's FOREACH.
> >
> > 1)
> > (from https://bugzilla.redhat.com/show_bug.cgi?id=1425273)
> > The simplest reproducer of this is:
> >
> > ./qemu-system-x86_64 -nographic -device e1000e,id=foo -m 1G -M
> > pc,accel=kvm my.img
> >
> > with a Linux image and after it's booted do a device_del foo
> >
> > migration at that point sees an empty RAMBlock that was the ROM
> > associated with the device. This doesn't happen on an e1000 device,
> > so I've not figured out what the difference is.
> >
> > This gives a : Unknown ramblock "", cannot accept migration
> > on the destination (correctly).
> >
> > (This happens on 2.7.0 as well, so it's nothing new)
> >
> > 2)
> > ./qemu-system-x86_64 -nographic -object
> > memory-backend-file,id=mem,size=512M,mem-path=/tmp
> >
> > Note I've not wired that memory to a NUMA node or a DIMM or anything, so
> > it's just hanging around.
> > Again that RAMBlock does exist and shows up in the migration code,
> > I think it'll try and migrate it.
> it has to be registered with vmstate_register_ram() which
> doesn't happen for non used hostmem object.
> See:
> pc_dimm_memory_plug()
> and
> memory_region_allocate_system_memory()
>
> > The real fun is that there doesn't seem to be anything that stops
> > two blocks having the same name!
> code doesn't permit duplicate ids for -object created objects
> but memory region api doesn't care about it as long as
> memory_region name is unique child name within its parent object
> children namespace.
>
> you can do a check for empty / duplicate names at ram_block_add()
> time and fail gracefully, but that probably will break things as
> it hasn't been expected behavior before.
There's actually code to check for setting duplicate RAMBlock names;
what isn't caught is where two RAMBlocks have never had their names
set or where they've been unset.
I'm tempted to add a check at the start of migration; if one of these
blocks exists during a migration it'll probably succeed; two of them
however will cause chaos.
Dave
>
> >
> > Dave
> >
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK