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/
Home Products Support Community News


Re: [Xen-devel] netif & grant tables

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] netif & grant tables
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Sun, 3 Jul 2005 18:12:31 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Matt Chapman <matthewc@xxxxxx>
Delivery-date: Sun, 03 Jul 2005 22:11:25 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200507021634.58540.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
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 07/02/2005 11:34:58 AM:

> > It could be done implicitly, meaning that if you give a domain a 
> > (netif/blkif), that privilege flag will automatically be set by XEN-D 
> > used when creating the domain, or explicitly where one specifies the
> > flag(s) to set in the VM config file.
> Doing it implicitly would probably be sensible.
> > From what I can see this does not work anymore - I used to do that 
> > Passing a PCI device to a partition results in an error since the
> > xc_physdev_pci_access_modify call ends in an error.
> Assigning PCI devices is broken in unstable at the moment.  It'll be 
> back at some stage.
> > I am not sure how 'privilege' is defined.
> Very coarsely at present: IIRC right now domain who's got access to a 
> device is as privileged as dom0.  This means they're allowed to map 
memory of 
> other domains, do dom0 ops, etc.
> Grant tables will enable us to deprivilege guests somewhat, then we'll 
> privileges down into more fine-grained capabilities.
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?


> Cheers,
> Mark
> > The privilege does so far not 
> > only mean to do dom 0 ops, but seems to also limit guest domains of 
> > other things - like the backend problem I see. I agree, though, that 
> > 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