From: Paolo Bonzini <pbonzini@redhat.com>
To: Fam Zheng <famz@redhat.com>, Peter Xu <peterx@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>,
lcapitulino@redhat.com, Laszlo Ersek <lersek@redhat.com>,
armbru@redhat.com, qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <565452A7.6050406@redhat.com> (raw)
In-Reply-To: <20151124031027.GC26733@ad.usersys.redhat.com>
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
next prev parent reply other threads:[~2015-11-24 12:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 10:07 [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory Peter Xu
2015-11-23 10:07 ` [Qemu-devel] [PATCH REPOST 1/2] dump-guest-memory: add "detach" flag for QMP/HMP interfaces Peter Xu
2015-11-23 15:48 ` Andrew Jones
2015-11-23 16:10 ` Eric Blake
2015-11-24 2:40 ` Fam Zheng
2015-11-23 10:07 ` [Qemu-devel] [PATCH REPOST 2/2] dump-guest-memory: add basic "detach" support Peter Xu
2015-11-23 15:56 ` Daniel P. Berrange
2015-11-23 16:08 ` Andrew Jones
2015-11-23 16:09 ` [Qemu-devel] [PATCH REPOST 0/2] Add basic "detach" support for dump-guest-memory Eric Blake
2015-11-23 16:22 ` Laszlo Ersek
2015-11-23 17:57 ` Andrew Jones
2015-11-24 1:57 ` Peter Xu
2015-11-24 3:10 ` Fam Zheng
2015-11-24 11:14 ` Laszlo Ersek
2015-11-24 11:37 ` Fam Zheng
2015-11-24 13:49 ` Eric Blake
2015-11-25 2:46 ` Fam Zheng
2015-11-25 4:48 ` Peter Xu
2015-11-25 4:57 ` Fam Zheng
2015-11-25 8:37 ` Markus Armbruster
2015-11-24 12:05 ` Paolo Bonzini [this message]
2015-11-24 13:36 ` Laszlo Ersek
2015-11-24 14:32 ` Paolo Bonzini
2015-11-25 5:07 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=565452A7.6050406@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=drjones@redhat.com \
--cc=famz@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=lersek@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).