From: Igor Druzhinin <igor.druzhinin@citrix.com>
To: xen-devel@lists.xenproject.org, qemu-devel@nongnu.org
Cc: Igor Druzhinin <igor.druzhinin@citrix.com>,
sstabellini@kernel.org, anthony.perard@citrix.com,
paul.durrant@citrix.com, pbonzini@redhat.com
Subject: [Qemu-devel] [PATCH v2 0/4] xen: don't save/restore the physmap on VM save/restore
Date: Tue, 4 Jul 2017 16:47:43 +0100 [thread overview]
Message-ID: <1499183267-28623-1-git-send-email-igor.druzhinin@citrix.com> (raw)
Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortunately, in Xen environment
VRAM memory does actually belong to a guest - not QEMU itself -
which means the position of this region is unknown beforehand and
can't be mapped into QEMU address space immediately.
Previously, recreating xenstore keys, holding the physmap, by the
toolstack helped to get this information in place at the right
moment ready to be consumed by QEMU to map the region properly.
But using xenstore for it has certain disadvantages: toolstack
needs to be aware of these keys and save/restore them accordingly;
accessing xenstore requires extra privileges which hinders QEMU
sandboxing.
The previous attempt to get rid of that was to remember all the
VRAM pointers during QEMU initialization phase and then update
them all at once when an actual foreign mapping is established.
Unfortunately, this approach worked only for VRAM and only for
a predefined set of devices - stdvga and cirrus. QXL and other
possible future devices using a moving emulated MMIO region
would be equally broken.
The new approach leverages xenforeignmemory_map2() call recently
introduced in libxenforeignmemory. It allows to create a dummy
anonymous mapping for QEMU during its initialization and change
it to a real one later during machine state restore.
---
Changed in v2:
* Patch 2: set dummy flag in a new flags field in struct MapCacheEntry
* Patch 3: change xen_remap_cache_entry name and signature
* Patch 3: gate ram_block_notify_* functions in xen_remap_bucket
* Patch 3: rewrite the logic of xen_replace_cache_entry_unlocked to
reuse the existing entry instead of allocating a new one
* Patch 4: don't use xen_phys_offset_to_gaddr in non-compat mode
---
Igor Druzhinin (4):
xen: move physmap saving into a separate function
xen/mapcache: add an ability to create dummy mappings
xen/mapcache: introduce xen_replace_cache_entry()
xen: don't use xenstore to save/restore physmap anymore
configure | 18 +++++++
hw/i386/xen/xen-hvm.c | 105 ++++++++++++++++++++++++++---------------
hw/i386/xen/xen-mapcache.c | 107 ++++++++++++++++++++++++++++++++++++++----
include/hw/xen/xen_common.h | 8 ++++
include/sysemu/xen-mapcache.h | 11 ++++-
5 files changed, 201 insertions(+), 48 deletions(-)
--
2.7.4
next reply other threads:[~2017-07-04 15:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-04 15:47 Igor Druzhinin [this message]
2017-07-04 15:47 ` [Qemu-devel] [PATCH v2 1/4] xen: move physmap saving into a separate function Igor Druzhinin
2017-07-04 16:05 ` Paul Durrant
2017-07-05 22:16 ` Stefano Stabellini
2017-07-04 15:47 ` [Qemu-devel] [PATCH v2 2/4] xen/mapcache: add an ability to create dummy mappings Igor Druzhinin
2017-07-04 16:11 ` Paul Durrant
2017-07-05 22:38 ` Stefano Stabellini
2017-07-04 15:47 ` [Qemu-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry() Igor Druzhinin
2017-07-04 16:27 ` Paul Durrant
2017-07-04 16:34 ` Igor Druzhinin
2017-07-04 16:42 ` Paul Durrant
2017-07-04 16:46 ` Igor Druzhinin
2017-07-05 8:52 ` Paul Durrant
2017-07-05 22:39 ` Stefano Stabellini
2017-07-06 9:50 ` Paul Durrant
2017-07-05 22:38 ` Stefano Stabellini
2017-07-04 15:47 ` [Qemu-devel] [PATCH v2 4/4] xen: don't use xenstore to save/restore physmap anymore Igor Druzhinin
2017-07-05 22:38 ` Stefano Stabellini
2017-07-06 13:57 ` [Qemu-devel] [PATCH v2 0/4] xen: don't save/restore the physmap on VM save/restore no-reply
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=1499183267-28623-1-git-send-email-igor.druzhinin@citrix.com \
--to=igor.druzhinin@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=paul.durrant@citrix.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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).