From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Laurent Vivier" <lvivier@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Stefan Berger" <stefanb@linux.vnet.ibm.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Claudio Fontana" <cfontana@suse.de>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Stefan Berger" <stefanb@linux.ibm.com>
Subject: [PATCH resend v2 0/5] softmmu/memory_mapping: optimize dump/tpm for virtio-mem
Date: Tue, 20 Jul 2021 15:02:59 +0200 [thread overview]
Message-ID: <20210720130304.26323-1-david@redhat.com> (raw)
This is a resend of v2, now that RamDiscardManager is upstream. I retested
dumping with virtio-mem on shmem and it works as expected now.
---
Minor fixes and cleanups, followed by an optimization for virtio-mem
regarding guest dumps and tpm.
virtio-mem logically plugs/unplugs memory within a sparse memory region
and notifies via the RamDiscardMgr interface when parts become
plugged (populated) or unplugged (discarded).
Currently, guest_phys_blocks_append() appends the whole (sparse)
virtio-mem managed region and therefore tpm code might zero the hole
region and dump code will dump the whole region. Let's only add logically
plugged (populated) parts of that region, skipping over logically
unplugged (discarded) parts by reusing the RamDiscardMgr infrastructure
introduced to handle virtio-mem + VFIO properly.
v1 -> v2:
- "softmmu/memory_mapping: factor out adding physical memory ranges"
-- Simplify based on RamDiscardManager changes: add using a
MemoryRegionSection
- "softmmu/memory_mapping: optimize for RamDiscardManager sections"
-- Simplify based on RamDiscardManager changes
David Hildenbrand (5):
tpm: mark correct memory region range dirty when clearing RAM
softmmu/memory_mapping: reuse qemu_get_guest_simple_memory_mapping()
softmmu/memory_mapping: never merge ranges accross memory regions
softmmu/memory_mapping: factor out adding physical memory ranges
softmmu/memory_mapping: optimize for RamDiscardManager sections
hw/tpm/tpm_ppi.c | 4 ++-
softmmu/memory_mapping.c | 72 ++++++++++++++++++++++++----------------
2 files changed, 46 insertions(+), 30 deletions(-)
--
2.31.1
next reply other threads:[~2021-07-20 13:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-20 13:02 David Hildenbrand [this message]
2021-07-20 13:03 ` [PATCH resend v2 1/5] tpm: mark correct memory region range dirty when clearing RAM David Hildenbrand
2021-07-23 14:52 ` Peter Xu
2021-07-23 19:15 ` David Hildenbrand
2021-07-23 22:35 ` Peter Xu
2021-07-26 8:08 ` David Hildenbrand
2021-07-26 14:21 ` Peter Xu
2021-07-20 13:03 ` [PATCH resend v2 2/5] softmmu/memory_mapping: reuse qemu_get_guest_simple_memory_mapping() David Hildenbrand
2021-07-20 13:37 ` Stefan Berger
2021-07-20 13:45 ` David Hildenbrand
2021-07-20 13:03 ` [PATCH resend v2 3/5] softmmu/memory_mapping: never merge ranges accross memory regions David Hildenbrand
2021-07-20 13:26 ` Stefan Berger
2021-07-23 15:09 ` Peter Xu
2021-07-20 13:03 ` [PATCH resend v2 4/5] softmmu/memory_mapping: factor out adding physical memory ranges David Hildenbrand
2021-07-20 13:25 ` Stefan Berger
2021-07-23 15:09 ` Peter Xu
2021-07-20 13:03 ` [PATCH resend v2 5/5] softmmu/memory_mapping: optimize for RamDiscardManager sections David Hildenbrand
2021-07-23 15:28 ` Peter Xu
2021-07-23 18:56 ` David Hildenbrand
2021-07-23 22:33 ` Peter Xu
2021-07-26 7:51 ` David Hildenbrand
2021-07-26 15:24 ` 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=20210720130304.26323-1-david@redhat.com \
--to=david@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=cfontana@suse.de \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanb@linux.ibm.com \
--cc=stefanb@linux.vnet.ibm.com \
--cc=thuth@redhat.com \
/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).