[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] address space reorganization



> > 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).
> 
> Why not treat the functions that use special mm-instructions 
> (like the software RAID code) as critical sections that 
> cannot overlap with migration, and then have the guestOS 
> re-calibrate its use of these features upon arrival?

That works OK for the kernel, but you might have user space apps that
have adapted their behviour based on what the've found in /proc/cpuinfo.

A particularly nasty case is apps or libraries that go at 'cpuid'
directly, as we can't trap that instruction. I guess VMware have the
same problem, as I don't believe they translate ring 3 code.

As regards your proposed critical region, we already effectively do
this.  We don't recalibrate stuff after a migration yet though (some of
the tests are quite slow, so I'm not sure you'd want to do them all
anyhow).

Ian

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.