From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSrfU-0001iC-Nh for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:40:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSrfQ-0001gI-2z for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:40:48 -0500 Received: from [199.232.76.173] (port=57185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSrfP-0001gF-Vf for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:40:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51705) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSrfP-0001cL-C4 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:40:43 -0500 Message-ID: <4B45D642.3070009@redhat.com> Date: Thu, 07 Jan 2010 14:40:34 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B30EFDF.4060202@codemonkey.ws> <4B31F1BA.10005@redhat.com> <4B43D4E2.9050102@codemonkey.ws> <4B4402B1.1030605@redhat.com> <4B448F36.8030605@codemonkey.ws> <4B449467.4070606@redhat.com> <4B4494FC.1080907@codemonkey.ws> <4B449608.7040102@redhat.com> <4B4496E9.2030201@redhat.com> <20100106142231.GF2248@redhat.com> <4B449EE7.4050401@redhat.com> <4B44A2C6.4050504@redhat.com> <4B44A965.9040300@codemonkey.ws> <4B459550.6000202@redhat.com> <4B4598BC.4000206@redhat.com> <4B45A536.1070300@redhat.com> <4B45A851.5000401@redhat.com> <4B45AC18.8040003@redhat.com> <4B45C7EB.1010501@codemonkey.ws> <4B45C90C.1000507@redhat.com> <4B45CCCE.1010208@redhat.com> <4B45D170.7050000@redhat.com> <4B45D497.40200@codemonkey.ws> In-Reply-To: <4B45D497.40200@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm-devel , Gleb Natapov , "Michael S. Tsirkin" , John Cooper , dlaor@redhat.com, Alexander Graf , qemu-devel@nongnu.org On 01/07/2010 02:33 PM, Anthony Liguori wrote: > > There's another option. > > Make cpuid information part of live migration protocol, and then > support something like -cpu Xeon-3550. We would remember the exact > cpuid mask we present to the guest and then we could validate that we > can obtain the same mask on the destination. Currently, our policy is to only migrate dynamic (from the guest's point of view) state, and specify static state on the command line [1]. I think your suggestion makes a lot of sense, but I'd like to expand it to move all guest state, whether dynamic or static. So '-m 1G' would be migrated as well (but not -mem-path). Similarly, in -drive file=...,if=ide,index=1, everything but file=... would be migrated. This has an advantage wrt hotplug: since qemu is responsible for migrating all guest visible information, the migrator is no longer responsible for replaying hotplug events in the exact sequence they happened. In short, I think we should apply your suggestion as broadly as possible. [1] cpuid state is actually dynamic; repeated cpuid instruction execution with the same operands can return different results. kvm supports querying and setting this state. -- error compiling committee.c: too many arguments to function