On Tue, 7 Mar 2017 19:46:56 +0000 "Dr. David Alan Gilbert" <dgilb...@redhat.com> 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. > > Dave > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
