|
|
|
|
|
|
|
|
|
|
xen-ia64-devel
RE: [Xen-devel] Essay on an important Xen decision (long)
> > 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
|
|
|
|
|