From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1EeQ-00031r-Qc for qemu-devel@nongnu.org; Tue, 24 Nov 2015 09:32:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1EeL-0005IR-62 for qemu-devel@nongnu.org; Tue, 24 Nov 2015 09:32:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1EeL-0005IK-0P for qemu-devel@nongnu.org; Tue, 24 Nov 2015 09:32:53 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id B98F0C00124E for ; Tue, 24 Nov 2015 14:32:52 +0000 (UTC) References: <1448273262-13845-1-git-send-email-peterx@redhat.com> <56533D45.1060108@redhat.com> <20151123175759.GG3606@hawk.localdomain> <5653C422.3040307@redhat.com> <20151124031027.GC26733@ad.usersys.redhat.com> <565452A7.6050406@redhat.com> <565467E5.5050703@redhat.com> From: Paolo Bonzini Message-ID: <56547510.6000206@redhat.com> Date: Tue, 24 Nov 2015 15:32:48 +0100 MIME-Version: 1.0 In-Reply-To: <565467E5.5050703@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Fam Zheng , Peter Xu Cc: Andrew Jones , lcapitulino@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org On 24/11/2015 14:36, Laszlo Ersek wrote: > On 11/24/15 13:05, Paolo Bonzini wrote: >> >> >> On 24/11/2015 04:10, Fam Zheng wrote: >>> What about all the hot-plug commands that changes the memory layout? >> >> If the guest is stopped, they shouldn't. device_add does not enable new >> BARs for example, the guest does that after it receives the ACPI event >> for PCI hotplug (or similarly an interrupt for SHPC or PCIe hotplug). >> >> Actually I like the idea of background dump, and a separate thread is an >> obvious way to do it since QEMU's memory API is mostly thread safe. > > I'm not trying to reject this patch just because "I don't like it". I > perceive it as extremely risky, and I don't know enough to review it > with *full coverage*. If you're willing to review it, and Peter can > assume the responsibility of supporting it down the road, feel free to > go ahead. Understood. That's always the case on both the submitter and the maintainer sides. (That said, I'm not dump-guest-memory maintainer; but I _can_ make some promises on memory changes). Paolo