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,
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
