Re: [Xen-devel] address space reorganization

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 13 Apr 2005, at 20:29, Keir Fraser wrote:

> 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).
I chatted to Christian a bit about this and he changed my mind. There 
probably are some situations where a variable virt_start would be 
useful for us, although we still may not want to do it for an initial 
pae patch.
We need generally to think about how flexible we want to be in allowing 
migration between different machine configurations. Shoudl we require 
identical h/w specs, or allow differences in I/O devices, CPU and/or 
memory? We will already have to be careful about downgrading cpu specs 
when we migrate (e.g., Linux locks onto using multimedia instructions 
for software raid that are unavailable post-migrate). A pragmatic 
middleground may be that, if people want to migrate in a heterogeneous 
cluster, we require them to configure 'worst-case specs' up front when 
building a domain (e.g., lowest-spec cpu the domain should run on; 
biggest hypervisor address-space hole the domain should work with).
 -- Keir


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