From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clL4c-0007Gy-If for qemu-devel@nongnu.org; Tue, 07 Mar 2017 14:47:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clL4X-0001vh-KC for qemu-devel@nongnu.org; Tue, 07 Mar 2017 14:47:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49782) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1clL4X-0001vZ-E2 for qemu-devel@nongnu.org; Tue, 07 Mar 2017 14:47:01 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 553E5C04B943 for ; Tue, 7 Mar 2017 19:47:01 +0000 (UTC) Date: Tue, 7 Mar 2017 19:46:56 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20170307194617.GJ2869@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] RAMBlock's named "" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: quintela@redhat.com, marcel@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, lvivier@redhat.com 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. The real fun is that there doesn't seem to be anything that stops two blocks having the same name! Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK