From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1SIm-0002TN-1z for qemu-devel@nongnu.org; Wed, 25 Nov 2015 00:07:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1SIi-0007hQ-1q for qemu-devel@nongnu.org; Wed, 25 Nov 2015 00:07:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1SIh-0007hM-S0 for qemu-devel@nongnu.org; Wed, 25 Nov 2015 00:07:27 -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 1FC1D32D3BC for ; Wed, 25 Nov 2015 05:07:27 +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> From: Peter Xu Message-ID: <56554207.3020900@redhat.com> Date: Wed, 25 Nov 2015 13:07:19 +0800 MIME-Version: 1.0 In-Reply-To: <565452A7.6050406@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: Paolo Bonzini , Fam Zheng Cc: Andrew Jones , lcapitulino@redhat.com, Laszlo Ersek , armbru@redhat.com, qemu-devel@nongnu.org On 11/24/2015 08:05 PM, 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. > > However, qmp_dump_guest_memory should only proceed if the VM is stopped > and is not in incoming migration (RUN_STATE_INMIGRATE); as you prefer. > If the VM is stopped, there is no whack-a-mole; the memory should not be > touched after vm_stop returns. The only special case is incoming migration. > > Regarding thread-safety, the thread needs to take > qemu_mutex_ram_list_lock or rcu_read_lock in order to get the list of > RAM regions. Even better, build a list of MemoryRegions in advance > (protecting them with memory_region_ref) in the iothread, and consult it > during the dump. At the end you can use memory_region_unref to release > them. Hi, Paolo, Thanks for the comments. If any of you are interested in this function, I would like to make bold to take the ownership to move on to v2, with all the review comments adopted (it might be necessary to contain a basic query mechanism if there is a v2 patch, since I see that it's the one that most to be complaint about besides the risk that it might bring). Thanks. Peter > > Paolo >