RE: [Xen-ia64-devel] Re: PMT table for XEN/IA64 (was: RE:Transparentparavirtualization vs. xen paravirtualization)

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> >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".

Dan

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