qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory
Date: Tue, 24 Nov 2015 13:05:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0


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.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]