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] Re: RFC: Using grant table to give iomem permission

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: RFC: Using grant table to give iomem permission
From: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>
Date: Fri, 18 May 2007 15:50:43 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 18 May 2007 07:49:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2737A97.F2B4%keir@xxxxxxxxxxxxx>
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>
References: <C2737A97.F2B4%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2007-05-18 at 15:45 +0100, Keir Fraser wrote:
> On 18/5/07 15:14, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:
> 
> >>> Some questions from me:
> >>>  - does this approach seem sane?
> >> 
> >> There's no reason you shouldn't be able to use GNTMAP_host_map as usual, 
> >> and
> >> do refcounting in the active grant entry, also as usual.
> > 
> > OK.  My reluctance to do that was simply that I wasn't sure if the
> > operations that take place when doing a GNTMAP_host_map would conflict
> > with those when doing an iomem_map.  If you think they shouldn't, I'll
> > give it a go.
> 
> I'm not sure what you mean.

That if GNTMAP_host_map is specified, the map/unmap operations do a
number of things that might not be appropriate.  eg.

    if ( op->flags & GNTMAP_host_map )
    {
        rc = create_grant_host_mapping(op->host_addr, frame, op->flags);
        if ( rc != GNTST_okay )
        {
            if ( !(op->flags & GNTMAP_readonly) )
                put_page_type(mfn_to_page(frame));
            put_page(mfn_to_page(frame));
            goto undo_out;
        }

I could prevent it doing these things in the case of it being iomem, but
in that case I felt that it was no longer really doing a host_map
operation, and so to avoid confusion (e.g. others maintaining the code
might not realise that GNTMAP_host_map can mean two different things)
thought it better to give it a separate type.

> > That raises one of my other questions which is how to test for it being
> > a valid RAM page, as in the absence of it GNTMAP_iomem_map that's pretty
> > much the only indicator that it's iomem we're dealing with.  As I said,
> > mfn_valid() doesn't seem to be sufficient.
> 
> Yes, I misled you here. You want the middle bit of get_page_from_l1e(). It
> checks for !mfn_valid()||page_get_owner()==dom_io. Then you'd do an
> iomem_access_permitted check passing in a pointer to the granting domain.
> 
> You should perhaps pull the core of get_page_from_l1e() into a supporting
> function which you can then make available for common/grant_table.c to call
> into.

Very helpful, thanks

Kieran


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