From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG4ze-0001bh-N0 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:25:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RG4zZ-0007de-AR for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:25:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG4zZ-0007dQ-2s for qemu-devel@nongnu.org; Tue, 18 Oct 2011 04:25:45 -0400 Date: Tue, 18 Oct 2011 09:25:38 +0100 From: "Daniel P. Berrange" Message-ID: <20111018082538.GF13556@redhat.com> References: <20111008151622.GA17181@amd.home.annexia.org> <4E916035.5050906@web.de> <20111009102338.GN16799@amd.home.annexia.org> <4E92568E.2010507@cn.fujitsu.com> <4E929618.4040403@web.de> <20111010090246.GF9408@redhat.com> <4E92BC11.3030508@siemens.com> <4E9D2791.5070207@cn.fujitsu.com> <20111018075806.GD13556@redhat.com> <4E9D3617.4060205@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E9D3617.4060205@siemens.com> Subject: Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , "Richard W.M. Jones" , Luiz Capitulino On Tue, Oct 18, 2011 at 10:17:27AM +0200, Jan Kiszka wrote: > On 2011-10-18 09:58, Daniel P. Berrange wrote: > > On Tue, Oct 18, 2011 at 03:15:29PM +0800, Wen Congyang wrote: > >> Hi, Jan Kiszka > >> > >> At 10/10/2011 05:34 PM, Jan Kiszka Write: > >>> On 2011-10-10 11:02, Daniel P. Berrange wrote: > >>>> On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote: > >> > >>> > >>> Run gdb with "set debug remote 1" and watch the communication, it is not > >>> that complex. But a dump command is probably simpler for those > >>> scenarios, I agree. > >> > >> I have implemented the command dump and reuse migration's code. But I meet a problem > >> when I test it. > >> > >> My qemu-kvm's tree is not updated about 2 months ago, because kernel.org is down, and > >> I forgot to pull from github. > >> > >> After I pull it from github, I find the following changes: > >> @@ -1523,9 +1523,7 @@ static void assigned_dev_unregister_msix_mmio(AssignedDevice *dev) > >> > >> static const VMStateDescription vmstate_assigned_device = { > >> .name = "pci-assign", > >> - .fields = (VMStateField []) { > >> - VMSTATE_END_OF_LIST() > >> - } > >> + .unmigratable = 1, > >> }; > >> > >> static void reset_assigned_device(DeviceState *dev) > >> > >> Why do you remove fields from vmstate_assigned_device? > >> It is useful for dump because it does not check unmigratable. If vmstate_assigned_device > >> does not contain .fields, qemu will crash in vmstate_save_state(). > > > > Given that '.fields' is allowed to be NULL for some devices, I'd say > > even for normal migration, QEMU should be checking for NULL in the > > vmstate_save_state() code. This would prevent QEMU crashes in the case > > where someone removed the .unmigratable member, but forgot to add back > > a .fields member. > > That crash wouldn't be bad because removinb unmigratable without adding > proper fields is almost always a bug. This is the kind of example of why QEMU is too crashy in general. We should be defensive against such bugs, by checking that preconditions are valid in the code, even if we don't expect them to happen often. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|