| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] address space reorganization
On 13 Apr 2005, at 18:59, Gerd Knorr wrote:
If we touch the address space anyway we might fix some other
issues along the way. Ian mentioned he wants to move the
ioremap area to the bottom. I guess next to the ro MPT
table, so it's easy to grant domains read-only access to
ACPI tables?
Ian was talking about the ioremap area in XenLinux, not in Xen. Doing
this for XenLinux would be useful if we were to make HYPERVISOR_START a
run-time, rather than compile-time, constant. However, I am not
convinced that this is a very good idea (see my reasoning below).
That given, it is also not clear that reorg'ing the Xen address space
is a worthwhile effort. Yes, things like the location of the Xen heap
will be different on PAE vs. non-PAE builds, but it will still be a
constant decided at compile time. Reorg'ing is hopefully a pain we can
do without for the time being. We should revisit these considerations
if/when we want a single Xen binary that can do both PAE and non-PAE.
But let's just get the basic support working first. :-)
Is it possible (and/or useful) to make the address layout
dynamic? So the size of the frametable can be adjusted at
boot time depending on the amount of memory installed in the
machine? That would imply the ro MPT doesn't have a fixed
address any more, not sure this is possible ...
I do not think that we should have run-time selected
HYPERVISOR_VIRT_START. This is because it will make it impossible to
migrate a guest to a machine with more memory than the one on which it
is currently executing.
The reasoning is: the new target machine will have a lower
HYPERVISOR_VIRT_START, but the guest will have sized its lowmem area
according to the available space on the original machine. It therefore
cannot run on the new target because its lowmem area simply will not
fit.
I think we should just fix on two VIRT_START values: -64MB for non-PAE
and something like -192MB for PAE (or whatever allows us to map up to
16GB -- I think we will treat bigger memory configs than that as rare
enough to ignore).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home