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] Re: [PATCH] xen: modify kernel mappings corresponding to

On Wed, Aug 10, 2011 at 09:06:04AM +0100, Ian Campbell wrote:
> On Tue, 2011-08-09 at 16:50 +0100, Konrad Rzeszutek Wilk wrote:
> > > > So I hadn't looked at this in detail, but I wonder if we can use the
> > > > MULTIcall for this? It looks like we need to do two hypercalls so why
> > > > not batch it?
> > > 
> > > That was going to be my next question. We should definitely batch these
> > > if possible.
> > > 
> > > > And while we are it - we could change the MMU ops to only do this on
> > > > initial domain and for the domU case do the old mechanism?
> > > 
> > > We need this in domU for driver domains and the like, don't we?
> > 
> > Sure, but I believe the majority of domU domains would not require this.
> 
> The overhead of this stuff is low if not used, isn't it? Compared with
> the complexity of having domains know if they might be used as a driver
> domain or not that seems like the tradeoff to be aiming for.
> 
> > I was thinking that when we start playing with the device/driver domains
> > we would want to escalate the privilige level (or perhaps not)?
> 
> We don't want any escalation of privilege over and above what is
> necessary to be a driver domain, which is generally none.
> 
> >  Or
> > perhaps introcuce a new type - "if (xen_driver_domain())" to recognize
> > that we are special ?
> 
> Where does the information to set xen_driver_domain == TRUE come from?

No idea. Was just thinking about it.. but you have convienced me it
is not worth looking at.

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