From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47412 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMMtL-00089X-J2 for qemu-devel@nongnu.org; Wed, 09 Jun 2010 11:08:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMMtJ-00050J-QB for qemu-devel@nongnu.org; Wed, 09 Jun 2010 11:08:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58737) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMMtJ-0004zk-JN for qemu-devel@nongnu.org; Wed, 09 Jun 2010 11:08:29 -0400 Message-ID: <4C0FAE67.3010002@redhat.com> Date: Wed, 09 Jun 2010 18:08:23 +0300 From: Avi Kivity MIME-Version: 1.0 References: <215BBDE4-B30E-4E55-8AC7-3B7C25662FAC@dlh.net> <4C0E09C0.9060300@dlh.net> <4C0E29B6.7060302@redhat.com> <4C0E2A1E.6080609@redhat.com> <4C0E2ECC.5090806@redhat.com> <4C0E3C46.30901@dlh.net> <4C0E3CD5.4070202@redhat.com> <4C0E4576.8030609@dlh.net> <4C0E46ED.5030305@redhat.com> <4C0E47C3.1050409@dlh.net> <4C0E484D.4060609@redhat.com> <4C0E492F.6060203@dlh.net> <4C0E495C.8020008@redhat.com> <4C0F50ED.7060109@dlh.net> In-Reply-To: <4C0F50ED.7060109@dlh.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 06/09/2010 11:29 AM, Peter Lieven wrote: > Avi Kivity wrote: >> On 06/08/2010 04:44 PM, Peter Lieven wrote: >>>> -cpu host is good if you have identical machines and don't plan to >>>> add new ones. >>> >>> i will likely add new ones, but my plan would be to use qemu64 and >>> then add all flags manually that >>> are common to all cpus in the pool. >>> would that be safe? >> >> Yes. >> > 2 last questions: > > a) i remember that there (have been) are instructions that have a high > virtualization penalty. > are there flags that should better not be offered to a VM? Not that I know of. > b) you told you fixed another bug in 2.6.35. is the nx virtualization > not working in guests > before 2.6.35 and therefore my case worked with 2.6.34? On 2.6.34, your guest lost nx protection after migration. On 2.6.35, it died. -- error compiling committee.c: too many arguments to function