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-api

Re: [Xen-API] New API Document and C Bindings

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Fri, 15 Sep 2006 01:50:54 +0100
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 14 Sep 2006 17:51:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF725B0774.686BDD4D-ON852571EA.00016BDE-852571EA.0001B710@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <OF80975B35.2A298B34-ON882571E9.007CB7DC-882571E9.007E1222@xxxxxxxxxx> <OF725B0774.686BDD4D-ON852571EA.00016BDE-852571EA.0001B710@xxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Sep 14, 2006 at 08:18:44PM -0400, Stefan Berger wrote:
> xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/14/2006 06:57:01 PM:
> 
> > Whilst I dont disagree that in Xen the Dom0 (and to be driver 
> > domains, stub domains, etc) have a lot of management characteristic 
> > in common with DomU's, in the fundamental DMTF System Virt model 
> > there is a clear distinction between the 'host' system - that which 
> > hands out resources/shares - and the 'virtual' or 'guest' systems - 
> > those whom consume these (virtualized) resources.
> > 
> > Of course, that said, there is no particular reason that the Xen API
> > and its objects must mirror this rather black-and-white distinction.
> > And in the case of when we start dealing with lots of different 
> > 'flavors' of domains, there is certianly now a bigger grey area as 
> > to what are pure "guest domains" and what are "management domains". 
> > eg I would have a much harder time justifying Dom0 as unique once 
> > all these other mgmt related domains come into the picture... And 
> > once we can have DomUs essentially 'managing' other DomUs in a 
> > front-end/back-end manner everything goes out the window! :-)
> 
> In that case I would suggest introducing a privileged flag for the VM 
> classes. Maybe that ends up being a distinguishing factor between VMs like 
> dom-0, driver domains and other guests.

Except that its not really representative of what's going on - it implies
a discrete set of privilege levels can be assigned to domains. Domains
aren't directly given privilege levels by the HV - they're granted privileged
access to hardware devices / memory regions. So for exmaple, Domain N may be
given privileged access to PCI device Y, and Domain M can be given access
to PCI device X. Domain N & M don't intrinsically have different privilege
levels, its the per-device access rights that's the interesting thing.
Domain-0 currently looks like it has a higher intrinsic privilege, but from
what I understand thats just an artifact of it being given access to all
harware - this won't neccessarily be true long term when hardware gets taken
away from Domain 0 & given directly to individual domains.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api