WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] address space reorganization

To: Gerd Knorr <kraxel@xxxxxxxxxxx>
Subject: Re: [Xen-devel] address space reorganization
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 13 Apr 2005 20:29:51 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 13 Apr 2005 19:26:26 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20050413175940.GA17666@bytesex>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20050413175940.GA17666@bytesex>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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