[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |