WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Next steps with pv_ops for Xen
From: Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Date: Wed, 05 Dec 2007 13:19:58 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Juan Quintela <quintela@xxxxxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, "virtualization@xxxxxxxxxxxxxx" <virtualization@xxxxxxxxxxxxxx>
Delivery-date: Wed, 05 Dec 2007 05:21:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4755B158.3030008@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1195682725.6726.48.camel@xxxxxxxxxxxxxxxxxxxxx> <4753FC6A.4020601@xxxxxxxxxx> <4754024C.7020905@xxxxxxxxxxxx> <47540FB8.8000106@xxxxxxxxxx> <475417E7.9070006@xxxxxxxxxxxx> <47546931.2090602@xxxxxxxxxx> <475520A1.6080909@xxxxxxxxxxxx> <475541A8.7030100@xxxxxxxxxx> <1196771999.10809.18.camel@xxxxxxxxxxxxxxxxxxxxx> <4755B158.3030008@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071115)
Gerd,

Can you try the attached patch against linux-2.6.18-xen.hg?

I think the problem was that the gntdev VMA is not marked as being VM_PFNMAP, therefore it tries to get a struct page_struct for each granted page when it is unmapped (and maybe sometimes succeeds (incorrectly), which could be why I haven't seen the bug). With this flag, vm_normal_page will return NULL in zap_pte_range, and so the code that decrements that reference count will not be executed.

Regards,

Derek.
# HG changeset patch
# User dgm36@xxxxxxxxxxxxxxxx
# Date 1196860382 0
# Node ID af26b3dd23822190acbec1872a47259e1fed88b8
# Parent  b2768401db943e66af9d64bd610ffa225f560c0b
Set gntdev VMA to be VM_PFNMAP.

diff -r b2768401db94 -r af26b3dd2382 drivers/xen/gntdev/gntdev.c
--- a/drivers/xen/gntdev/gntdev.c       Mon Dec 03 08:50:12 2007 +0000
+++ b/drivers/xen/gntdev/gntdev.c       Wed Dec 05 13:13:02 2007 +0000
@@ -501,6 +501,17 @@ static int gntdev_mmap (struct file *fli
     
        /* The VM area contains pages from another VM. */
        vma->vm_flags |= VM_FOREIGN;
+
+       /* The VM area contains pages that are not backed by page_structs in
+        * this domain's memory map.
+        *
+        * TODO/FIXME?: We should probably use the VM_FOREIGN workaround as
+        *              used by get_user_pages() to provide access to the
+        *              page_structs for each page, but I'm not sure if that's
+        *              necessary.
+        */
+       vma->vm_flags |= VM_PFNMAP;
+
        vma->vm_private_data = kzalloc(size * sizeof(struct page_struct *), 
                                       GFP_KERNEL);
        if (vma->vm_private_data == NULL) {
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel