Xen devel - Dec 2010 - [PATCH] xen: gntdev: move use of GNTMAP_contains_pte next to the map_op

This flag controls the meaning of gnttab_map_grant_ref.host_addr and
specifies that the field contains a refernce to the pte entry to be
used to perform the mapping. Therefore move the use of this flag to
the point at which we actually use a reference to the pte instead of
something else, splitting up the usage of the flag in this way is
confusing and potentially error prone.

The other flags are all properties of the mapping itself as opposed to
properties of the hypercall arguments and therefore it make sense to
continue to pass them round in map->flags.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Derek G. Murray <Derek.Murray@cl.cam.ac.uk>
Cc: Gerd Hoffmann <kraxel@redhat.com>
---
 drivers/xen/gntdev.c    |    5 +++--
 drivers/xen/hypercall.c |   18 ++++++++++++++----
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a33e443..295254b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -204,7 +204,8 @@ static int find_grant_ptes(pte_t *pte, pgtable_t token,
unsigned long addr, void
 	BUG_ON(pgnr >= map->count);
 	pte_maddr  = (u64)pfn_to_mfn(page_to_pfn(token)) << PAGE_SHIFT;
 	pte_maddr += (unsigned long)pte & ~PAGE_MASK;
-	gnttab_set_map_op(&map->map_ops[pgnr], pte_maddr, map->flags,
+	gnttab_set_map_op(&map->map_ops[pgnr], pte_maddr,
+			  GNTMAP_contains_pte | map->flags,
 			  map->grants[pgnr].ref,
 			  map->grants[pgnr].domid);
 	gnttab_set_unmap_op(&map->unmap_ops[pgnr], pte_maddr, map->flags,
@@ -577,7 +578,7 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
 	vma->vm_private_data = map;
 	map->vma = vma;
 
-	map->flags = GNTMAP_host_map | GNTMAP_application_map |
GNTMAP_contains_pte;
+	map->flags = GNTMAP_host_map | GNTMAP_application_map;
 	if (!(vma->vm_flags & VM_WRITE))
 		map->flags |= GNTMAP_readonly;
 
diff --git a/drivers/xen/hypercall.c b/drivers/xen/hypercall.c
index 4eb6b34..054826b 100644
--- a/drivers/xen/hypercall.c
+++ b/drivers/xen/hypercall.c
@@ -11,6 +11,7 @@
 #include <asm/xen/hypercall.h>
 
 struct mmap_hypercall {
+	spinlock_t lock;
 	struct list_head list;
 };
 
@@ -67,14 +68,16 @@ static void hypercall_vm_open(struct vm_area_struct * vma)
 static void hypercall_vm_close(struct vm_area_struct * vma)
 {
 	struct mmap_hypercall *priv = vma->vm_private_data;
-	struct page *page;
+	struct page *page, *tpage;
 	printk(KERN_CRIT "hypercall_vm_close: vma %p %#lx-%#lx (%#lx) priv
%p\n",
 	       vma, vma->vm_start, vma->vm_end, vma->vm_end -
vma->vm_start, priv);
 
-	list_for_each_entry(page, &priv->list, lru) {
+	spin_lock(&priv->lock);
+	list_for_each_entry_safe(page, tpage, &priv->list, lru) {
 		printk(KERN_CRIT "hypercall vm_close: page %p count %d\n", page,
page_count(page));
 		__free_page(page);
 	}
+	spin_unlock(&priv->lock);
 	vma->vm_private_data = NULL;
 	kfree(priv);
 }
@@ -99,8 +102,10 @@ static int hypercall_mmap(struct file *file, struct
vm_area_struct *vma)
 	printk(KERN_CRIT "hypercall interface mmaped by %s: vma %p %#lx-%#lx
(%#lx) priv %p\n",
 	       current->comm, vma, vma->vm_start, vma->vm_end, vma->vm_end
- vma->vm_start, priv);
 
+	spin_lock_init(&priv->lock);
 	INIT_LIST_HEAD(&priv->list);
 
+	spin_lock(&priv->lock);
 	for (address = vma->vm_start; address < vma->vm_end; address +=
PAGE_SIZE)
 	{
 		struct page *page = alloc_page(GFP_KERNEL|__GFP_ZERO);
//get_zeroed_page(GFP_KERNEL);
@@ -112,17 +117,22 @@ static int hypercall_mmap(struct file *file, struct
vm_area_struct *vma)
 		printk(KERN_CONT " vm_insert_page -> %d count %d", ret,
page_count(page));
 		if (ret) {
 			printk(KERN_CONT ": failure!\n");
-			return -EINVAL;
+			goto out_unlock;
 		}
 		printk(KERN_CONT " %p<-page->%p\n", page->lru.prev,
page->lru.next);
 		list_add_tail(&page->lru, &priv->list);
 	}
+	spin_unlock(&priv->lock);
 
-	vma->vm_flags |= VM_RESERVED | VM_DONTCOPY;
+	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
+	//vma->vm_flags |= VM_RESERVED | VM_DONTCOPY;
 	vma->vm_ops = &hypercall_vm_ops;
 	vma->vm_private_data = priv;
 
 	return 0;
+out_unlock:
+	spin_unlock(&priv->lock);
+	return -EINVAL;
 }
 
 static int hypercall_open(struct inode *inode, struct file *file)
-- 
1.5.6.5


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

On Wed, 2010-12-08 at 11:53 +0000, Ian Campbell wrote:
> This flag controls the meaning of gnttab_map_grant_ref.host_addr and
> specifies that the field contains a refernce to the pte entry to be
> used to perform the mapping. Therefore move the use of this flag to
> the point at which we actually use a reference to the pte instead of
> something else, splitting up the usage of the flag in this way is
> confusing and potentially error prone.
> 
> The other flags are all properties of the mapping itself as opposed to
> properties of the hypercall arguments and therefore it make sense to
> continue to pass them round in map->flags.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
> Cc: Derek G. Murray <Derek.Murray@cl.cam.ac.uk>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  drivers/xen/gntdev.c    |    5 +++--
>  drivers/xen/hypercall.c |   18 ++++++++++++++----
Damn, a bunch of other hacking got added here by mistake, I''ll resend!



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

This flag controls the meaning of gnttab_map_grant_ref.host_addr and
specifies that the field contains a refernce to the pte entry to be
used to perform the mapping. Therefore move the use of this flag to
the point at which we actually use a reference to the pte instead of
something else, splitting up the usage of the flag in this way is
confusing and potentially error prone.

The other flags are all properties of the mapping itself as opposed to
properties of the hypercall arguments and therefore it make sense to
continue to pass them round in map->flags.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Cc: Derek G. Murray <Derek.Murray@cl.cam.ac.uk>
Cc: Gerd Hoffmann <kraxel@redhat.com>
---
 drivers/xen/gntdev.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a33e443..ac87e62 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -204,10 +204,12 @@ static int find_grant_ptes(pte_t *pte, pgtable_t token,
unsigned long addr, void
 	BUG_ON(pgnr >= map->count);
 	pte_maddr  = (u64)pfn_to_mfn(page_to_pfn(token)) << PAGE_SHIFT;
 	pte_maddr += (unsigned long)pte & ~PAGE_MASK;
-	gnttab_set_map_op(&map->map_ops[pgnr], pte_maddr, map->flags,
+	gnttab_set_map_op(&map->map_ops[pgnr], pte_maddr,
+			  GNTMAP_contains_pte | map->flags,
 			  map->grants[pgnr].ref,
 			  map->grants[pgnr].domid);
-	gnttab_set_unmap_op(&map->unmap_ops[pgnr], pte_maddr, map->flags,
+	gnttab_set_unmap_op(&map->unmap_ops[pgnr], pte_maddr,
+			    GNTMAP_contains_pte | map->flags,
 			    0 /* handle */);
 	return 0;
 }
@@ -577,7 +579,7 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
 	vma->vm_private_data = map;
 	map->vma = vma;
 
-	map->flags = GNTMAP_host_map | GNTMAP_application_map |
GNTMAP_contains_pte;
+	map->flags = GNTMAP_host_map | GNTMAP_application_map;
 	if (!(vma->vm_flags & VM_WRITE))
 		map->flags |= GNTMAP_readonly;
 
-- 
1.5.6.5


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