[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Keir Fraser wrote:
Yes, this would work okay I suspect. Good enough as a stop-gap measure? Are
there any other responsibilities that you acquire if you make use of
VM_FOREIGN (in particular, how would this affect get_user_pages)?

VM_FOREIGN is already set for the gntdev VMA (mostly because it's directly based on the blktap code). That means that it has the array of page_structs in its vm_private_data, which can be used to fulfill a get_user_pages call. I've attached a patch based on this fix.

Regards,

Derek.
# HG changeset patch
# User dgm36@xxxxxxxxxxxxxxxx
# Date 1196878124 0
# Node ID df7d0555ec3847bd5915063d8ee79123d6ebc67a
# Parent  ba918cb2cf7520604dee724dd80dad5ce4bee8a1
Changed vm_normal_page to return NULL when presented with a VMA marked
as being VM_FOREIGN.

Signed-off-by: Derek Murray <Derek.Murray@xxxxxxxxxxxx>

diff -r ba918cb2cf75 -r df7d0555ec38 mm/memory.c
--- a/mm/memory.c       Tue Dec 04 11:54:22 2007 +0000
+++ b/mm/memory.c       Wed Dec 05 18:08:44 2007 +0000
@@ -395,6 +395,9 @@ struct page *vm_normal_page(struct vm_ar
                if (!is_cow_mapping(vma->vm_flags))
                        return NULL;
        }
+
+       if (unlikely(vma->vm_flags & VM_FOREIGN))
+               return NULL;
 
        /*
         * Add some anal sanity checks for now. Eventually,
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.