WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RFC: Using grant table to give iomem permission

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] RFC: Using grant table to give iomem permission
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Fri, 18 May 2007 15:01:23 +0100
Delivery-date: Fri, 18 May 2007 06:59:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
It used to be possible to use domctl to programatically set up
permissions for other domains to map iomem regions.  However, domctl is
no longer accessible from drivers (only from tools).  After some
discussion with Keir about how to achieve this functionality, it was
suggested that it might be possible to use the grant table operations to
do it.  

Attached is a patch that has a go at this and seems to work.  However,
it is quite primitive and I would welcome the comments of others who
know more about the grant tables than I do!

The patch adds a new type of grant (GNTMAP_iomem_map) to complement
GNTMAP_device_map and GNTMAP_host_map.

The granting domain would do a normal grant operation to specify the
region that can be used as iomem:
        err = gnttab_grant_foreign_access(dev->otherend_id, mfn, 0)
and then pass the grant ref to the mapping domain.

The mapping domain would then do a map op, along the lines of:
        struct gnttab_map_grant_ref op;
        gnttab_set_map_op(&op, 0, GNTMAP_iomem_map, gnt_ref, dev->otherend_id);
        if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
                BUG();

When the hypervisor tries to do this grant in xen/common/grant_table.c
it (i) notices that it is an iomem_map rather than device_map or
host_map; (ii) it is from dom0; and (iii) it is not a RAM page.  It then
attempts to call iomem_permit_access().

If successful, on return, the mapping domain should then be able to call
ioremap() to access the page in question.

When finished, the mapping domain can similarly unmap the grant, which
removes its ability to ioremap() the page:
        struct gnttab_unmap_grant_ref op;
        gnttab_set_unmap_op(&op, 0, GNTMAP_iomem_map, handle);
        if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
                BUG();

Some questions from me:
 - does this approach seem sane?

 - any problem with adding the GNTTAB_iomem_map type?

 - how about the current test for it being a RAM page: !mfn_valid
(frame).  I've seen this return "valid" on iomem pages on a machine with
4GB of RAM, so it may not be a good/sufficient test.

 - the current patch doesn't actually do the ioremap() as part of the
grant operation, it just sets up the permissions.  I can see that others
might prefer it to do both.  Any thoughts?

 - is there some gross omission from what I've done?

Thanks

Kieran

Attachment: iomem_grants
Description: Text Data

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