From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Kevin Tian <kevin.tian@intel.com>,
Jan Beulich <jbeulich@suse.com>,
David Vrabel <david.vrabel@citrix.com>,
Jun Nakajima <jun.nakajima@intel.com>
Subject: [PATCHv1 2/3] mm: don't free pages until mm locks are released
Date: Fri, 6 Nov 2015 17:37:16 +0000 [thread overview]
Message-ID: <1446831437-5897-3-git-send-email-david.vrabel@citrix.com> (raw)
In-Reply-To: <1446831437-5897-1-git-send-email-david.vrabel@citrix.com>
If a page is freed without translations being invalidated, and the page is
subsequently allocated to another domain, a guest with a cached
translation will still be able to access the page.
Currently translations are invalidated before releasing the page ref, but
while still holding the mm locks. To allow translations to be invalidated
without holding the mm locks, we need to keep a reference to the page
for a bit longer in some cases.
[ This seems difficult to a) verify as correct; and b) difficult to get
correct in the future. A better suggestion would be useful. Perhaps
using something like pg->tlbflush_needed mechanism that already exists
for pages from PV guests? ]
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
xen/arch/x86/mm/p2m.c | 4 ++++
xen/common/memory.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index ed0bbd7..e13672d 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2758,6 +2758,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
p2m_type_t p2mt, p2mt_prev;
unsigned long prev_mfn, mfn;
struct page_info *page;
+ struct page_info *prev_page = NULL;
int rc;
struct domain *fdom;
@@ -2805,6 +2806,9 @@ int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
prev_mfn = mfn_x(get_gfn(tdom, gpfn, &p2mt_prev));
if ( mfn_valid(_mfn(prev_mfn)) )
{
+ prev_page = mfn_to_page(_mfn(prev_mfn));
+ get_page(prev_page, tdom);
+
if ( is_xen_heap_mfn(prev_mfn) )
/* Xen heap frames are simply unhooked from this phys slot */
guest_physmap_remove_page(tdom, gpfn, prev_mfn, 0);
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a3bffb7..571c754 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -272,8 +272,8 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
guest_physmap_remove_page(d, gmfn, mfn, 0);
- put_page(page);
put_gfn(d, gmfn);
+ put_page(page);
return 1;
}
--
2.1.4
next prev parent reply other threads:[~2015-11-06 17:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-06 17:37 [RFC PATCHv1 0/3]: x86/ept: reduce translation invalidation impact David Vrabel
2015-11-06 17:37 ` [PATCHv1 1/3] x86/ept: remove unnecessary sync after resolving misconfigured entries David Vrabel
2015-11-06 18:29 ` Andrew Cooper
2015-11-10 12:22 ` Jan Beulich
2015-11-12 16:18 ` David Vrabel
2015-11-12 16:30 ` Jan Beulich
2015-11-06 17:37 ` David Vrabel [this message]
2015-11-06 17:37 ` [PATCHv1 3/3] x86/ept: defer the invalidation until the p2m lock is released David Vrabel
2015-11-06 18:39 ` Andrew Cooper
2015-11-09 14:13 ` Jan Beulich
2015-11-10 13:35 ` Tim Deegan
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=1446831437-5897-3-git-send-email-david.vrabel@citrix.com \
--to=david.vrabel@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.