Re: [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory

[Peter Xu <peterx@redhat.com>]

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
>