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. > 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 >
