From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: address space reorganization Date: Wed, 13 Apr 2005 19:18:28 -0700 Message-ID: <425DD2F4.7070400@diku.dk> References: <20050413175940.GA17666@bytesex> <5bf6d41cfb5c053d0265b190a37fa795@cl.cam.ac.uk> <08282afe301ad10a5073e6b2522be52c@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <08282afe301ad10a5073e6b2522be52c@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Gerd Knorr List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > 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? [ insert standard plug of self-migration here :-) ] Jacob