From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: AMD-Intel guest migration and CPUs without NX Date: Tue, 24 Mar 2009 14:40:04 +0200 Message-ID: <49C8D4A4.2000606@redhat.com> References: <49C8BA8F.8000008@wpkg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Tomasz Chmielewski Return-path: Received: from mx2.redhat.com ([66.187.237.31]:49338 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759485AbZCXMkK (ORCPT ); Tue, 24 Mar 2009 08:40:10 -0400 In-Reply-To: <49C8BA8F.8000008@wpkg.org> Sender: kvm-owner@vger.kernel.org List-ID: Tomasz Chmielewski wrote: > I have an older Intel CPU which doesn't support NX (/proc/cpuinfo - > below). Is it safe to migrate guests running on newer CPUs to this > older CPU? I made some simple tests and migration works, but I'm not > sure if the guests will be stable after such migration. > > > I'm also a bit confused a bit over what the documentation says: > > According to http://www.linux-kvm.org/page/Migration: > > There are some older Intel processors which don't support NX (or XD), > which may cause problems in a cluster which includes NX-supporting > hosts. We may add a feature to hide NX if this proves to be a problem > in actual deployments. > > > So the above says I may have some problems. Right, it's not safe in general. It may work if the guest doesn't use NX. It may also work if the guest does not rely on NX working properly. > > On the other hand, FAQ below seems to indicate that migration on 64 > bit hosts should be fine (even when they don't support NX?), only 32 > bit hosts may have problems: > > http://www.linux-kvm.org/page/FAQ > > Yes. There may be issues on 32-bit Intel hosts which don't support NX > (or XD), but for 64-bit hosts back and forth migration should work > well. Migration of 32-bit guests should work between 32-bit hosts and > 64-bit hosts. Looks like that paragraph assumes that all 64-bit hosts have NX. Your /proc/cpuinfo proves otherwise. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.