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-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentpara

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Matt Chapman" <matthewc@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 1 Nov 2005 08:42:50 -0800
Cc: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 01 Nov 2005 16:44:53 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXerXo76q/haFr+QWGubs2JLsu1/QAAmd0wAA7Ef8AAAiCdgAADn4WA
Thread-topic: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)
> >However, I agree with Matt that a PMT for other domains
> >(domU) is a bad idea as it creates many problems for migration,
> >save/restore, ballooning, and adding new domains to an already
> >loaded system. Further, the grant table abstraction is the primary
> >mechanism for page sharing for domU in Xen (on Xen/x86).
> >I think if domU has any knowledge of actual machine addresses,
> >the Xen team would consider this a bug that should be fixed.
> Here we need to clarify one concept. When domU behaves as a 
> driver domain, it becomes one necessary assistant to dom0 to 
> co-construct the virtual environment. At that time, the 
> driver domU should also be owned by system administrator like 
> dom0 since these domains controls physical resources. They 
> driver domU are just service provider (backend) as dom0 and 
> there's on need to migrate them. IMO, migration is mainly 
> applied to non-driver domU which are simply 
> service-subscriber (frontend). Then migration is necessary 
> for them by hooking them to different service-providers on 
> another machine.

OK.  I agree that "isolated driver domains (IDDs)" -- to use
the Xen term -- can also use a physical-to-machine mapping table.
IDDs don't exist right now even in Xen/x86.  I would like to wait
to see how Xen/x86 handles them before we support them in
Xen/ia64, but agree that we could, for example, test for
"d has the capability to run virtual driver backends" rather
than just test for "d == dom0".
> More, driver domains are necessary for server environment 
> (especially for IA64), and it would be nightmare to only have 
> one dom0 controls all physical resources and acts as only 
> backend to serve all other domains.

This depends on use model.  Driver domains may be more necessary
on a scale-up server which has many I/O slots but less necessary
on a scale-out server which has a single "fat pipe".


Xen-ia64-devel mailing list