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

Re: [Xen-devel] netif & grant tables

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] netif & grant tables
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Mon, 4 Jul 2005 14:43:15 -0400
Delivery-date: Mon, 04 Jul 2005 18:42:17 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200507040226.18182.mark.williamson@xxxxxxxxxxxx>
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
Sensitivity:
Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote on 07/03/2005 
09:26:18 PM:

> [off list]
> 
> > Setting the privileged bit in a user domain gets grant tables to work:
> > should this bit be set for those kind of domains or rather the 
IS_PRIV()
> > test be removed from the call path which basically would allow all 
user
> > domains to do mapping by default?
> 
> I'm not clear what you mean here - AFAIK grant tables don't require 
IS_PRIV() 
> in order to work.  Or am I misunderstanding?

You are right, it's not the grant tables per se that need the privileged 
bit to be set, but other functions need it and keep backends from working.

Here are two code paths from the network backend:

from netback/interface.c calls 
 
linux-2.6.11-xen-sparse/arch/xen/i386/mm/ioremap.c:direct_remap_area_pages() 
calls
      HYPERVISOR_mmu_update calls
         xen/arch/x86/mm.c:do_mmu_update calls
           set_foreigndom() which has an IS_PRIV() in the path
 
-> The direct_remap_area_pages call fails if a domain does not have the 
privilege bit set.


netback/netback.c: alloc_mfn() calls
   HYPERVISOR_dom_mem_op(MEMOP_increase_reservation, mfn_list, 
MAX_MFN_ALLOC, 0);
     xen/common/dom_mem_ops.c:do_dom_mem_op() is called which has a 
IS_PRIV() in the path



 Stefan


> 
> What I meant was that since grant tables are an explicit capability (you 
can 
> only map a page of another dom if it gave you an explicit grant) there's 
no 
> need for mappings in the IO path to require special privileges at all. 
If 
> someone gave you a grant, they must trust you enough to access that 
page.
> 
> Cheers,
> Mark
> 
> >     Stefan
> >
> > > Cheers,
> > > Mark
> > >
> > > > The privilege does so far not
> > > > only mean to do dom 0 ops, but seems to also limit guest domains 
of
> >
> > doing
> >
> > > > other things - like the backend problem I see. I agree, though, 
that
> >
> > for
> >
> > > > grant table support a backend should not need privileges.
> > > >
> > > > > Cheers,
> > > > > Mark
> > > >
> > > > Cheers,
> > > >    Stefan
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel


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