Re: Re: Next steps with pv_ops for Xen

[Derek Murray <Derek.Murray@cl.cam.ac.uk>]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

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.

[-- Attachment #2: gntdev_vm_foreign.patch --]
[-- Type: text/x-patch, Size: 714 bytes --]

# HG changeset patch
# User dgm36@ise.cl.cam.ac.uk
# 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@cl.cam.ac.uk>

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,

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel