| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-devel] Essay on an important Xen decision (long)
> So ia64 dom0 physical 0 is machine 0? Where does Xen live in machine
> space?
>
> PowerPC exception handlers are architecturally hardcoded to the first
> couple pages of memory, so Xen needs to live there. Linux
> expects it is
> booting at 0 of course, so dom0 runs in an offset physical address
> space.
On ia64, Xen (and Linux when booting natively) is relocatable.
Machine address 0 is not special on ia64 like it is on PowerPC.
> The trouble then comes when dom0 needs to access IO or domU memory;
> obviously dom0 must have some awareness of the machine space.
> Accordingly, I'm thinking I'm going to need to install p2m tables in
> dom0, and once they're there, why not have domU use them too?
On ia64, machine memory is exposed to a native OS via EFI (firmware)
tables. (I think these are similar to e820 on x86 machines and
don't know how this is done on PowerPC.) When Xen/ia64 starts domain0
(or a domU), it passes a faked EFI table. This table is faked
differently for domain0 and domU's. One solution, for example,
would be for Xen to "give" all machine memory to dom0, protecting
only a small portion for itself. Then when other domains are
created, all the memory for domUs would be "ballooned" from dom0.
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...
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home