RE: [Xen-devel] Essay on an important Xen decision (long)

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

> > On ia64, Xen (and Linux when booting natively) is relocatable.
> > Machine address 0 is not special on ia64 like it is on PowerPC.
> 
> Right, so P==M for dom0 (or any domain) will not work on PowerPC.

Are machine addresses 0-n the only range that are special?
And can one safely assume that DMA will never occur in this
range?  If so, then a single "special" mapping in the hypervisor
could get around this.  While I suppose this is more P~=M than
strictly P==M, it would seem a reasonable alternative to major Linux
changes.
  
> > Per the previous exchange with Anthony, there are many advantages
> > to being able to move memory around invisibly to domains, which
> > is easy with VP and much harder with P2M.  The current debate on
> > Xen/ia64 is just for domain0 but it could expand...
> 
> As far as I can see, dom0 must be aware of the machine 
> address space, so
> that means P2M for PowerPC. dom0 is a special case: do you really need
> to worry about migrating dom0, or memory compacting with 
> other domains?

No, migrating dom0 or any driver domain with direct device
access is unreasonable, at least unless all device access
is virtualized (e.g. Infiniband?).  I view domain0 as closer to
a semi-privileged extension of Xen.

Not sure what you mean by memory compacting...

> As for the question of domU being VP or P2M, I see no reason it
> shouldn't be VP. IO-capable domUs (driver domains) could be VP with
> proper IOMMU support. The PowerPC PAPR and Xen/ia64 implementations
> demonstrate that this works...

Ignoring the page table problems on x86 (which Vmware demonstrates
is more of a performance issue than a functional issue), if DMA can
be invisibly handled, I think everyone agrees that VP has significant
advantages over either P==M or P2M.

But to clarify, Xen/ia64 domU is currently VP only because it doesn't
do DMA. Driver domains will complicate this.

Dan




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