This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] [xen-unstable] xenpaging: update machine_to_phys_mapping

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] xenpaging: update machine_to_phys_mapping[] during page deallocation
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 17 Jan 2011 07:59:34 -0800
Delivery-date: Mon, 17 Jan 2011 08:12:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Keir Fraser <keir@xxxxxxx>
# Date 1294745257 0
# Node ID ca10302ac2859b43a41afe425d79ae0df29f2a9c
# Parent  c5b42971234a7b898d104e8db6a23432ff5a9e30
xenpaging: update machine_to_phys_mapping[] during page deallocation

The machine_to_phys_mapping[] array needs updating during page
deallocation.  If that page is allocated again, a call to
get_gpfn_from_mfn() will still return an old gfn from another guest.
This will cause trouble because this gfn number has no or different
meaning in the context of the current guest.

This happens when the entire guest ram is paged-out before
xen_vga_populate_vram() runs.  Then XENMEM_populate_physmap is called
with gfn 0xff000.  A new page is allocated with alloc_domheap_pages.
This new page does not have a gfn yet.  However, in
guest_physmap_add_entry() the passed mfn maps still to an old gfn
(perhaps from another old guest).  This old gfn is in paged-out state
in this guests context and has no mfn anymore.  As a result, the
ASSERT() triggers because p2m_is_ram() is true for p2m_ram_paging*
types.  If the machine_to_phys_mapping[] array is updated properly,
both loops in guest_physmap_add_entry() turn into no-ops for the new
page and the mfn/gfn mapping will be done at the end of the function.

If XENMEM_add_to_physmap is used with XENMAPSPACE_gmfn,
get_gpfn_from_mfn() will return an appearently valid gfn.  As a
result, guest_physmap_remove_page() is called.  The ASSERT in
p2m_remove_page triggers because the passed mfn does not match the old
mfn for the passed gfn.

Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
 xen/common/page_alloc.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletion(-)

diff -r c5b42971234a -r ca10302ac285 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c   Tue Jan 11 10:38:28 2011 +0000
+++ b/xen/common/page_alloc.c   Tue Jan 11 11:27:37 2011 +0000
@@ -527,7 +527,7 @@ static void free_heap_pages(
 static void free_heap_pages(
     struct page_info *pg, unsigned int order)
-    unsigned long mask;
+    unsigned long mask, mfn = page_to_mfn(pg);
     unsigned int i, node = phys_to_nid(page_to_maddr(pg)), tainted = 0;
     unsigned int zone = page_to_zone(pg);
@@ -538,6 +538,10 @@ static void free_heap_pages(
     for ( i = 0; i < (1 << order); i++ )
+        /* This page is not a guest frame any more. */
+        page_set_owner(&pg[i], NULL); /* set_gpfn_from_mfn snoops pg owner */
+        set_gpfn_from_mfn(mfn + i, INVALID_M2P_ENTRY);
          * Cannot assume that count_info == 0, as there are some corner cases
          * where it isn't the case and yet it isn't a bug:

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] xenpaging: update machine_to_phys_mapping[] during page deallocation, Xen patchbot-unstable <=