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

[Derek Murray <Derek.Murray@xxxxxxxxxxxx>]

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