From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSsdH-0005z9-Ji for qemu-devel@nongnu.org; Thu, 07 Jan 2010 08:42:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSsdC-0005xX-IR for qemu-devel@nongnu.org; Thu, 07 Jan 2010 08:42:34 -0500 Received: from [199.232.76.173] (port=50908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSsdC-0005xU-G4 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 08:42:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38830) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSsdC-00053k-0A for qemu-devel@nongnu.org; Thu, 07 Jan 2010 08:42:30 -0500 Message-ID: <4B45E4DE.8060100@redhat.com> Date: Thu, 07 Jan 2010 15:42:54 +0200 From: Dor Laor 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> <4B45D642.3070009@redhat.com> <4B45DE4A.6010608@codemonkey.ws> In-Reply-To: <4B45DE4A.6010608@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com 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 , Alexander Graf , qemu-devel@nongnu.org, Avi Kivity On 01/07/2010 03:14 PM, Anthony Liguori wrote: > On 01/07/2010 06:40 AM, Avi Kivity wrote: >> 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. It solves controlling the destination qemu execution all right but does not change the initial spawning of the original guest - to know whether ,-syscall is needed or not. Anyway, I'm in favor of it too. >> >> 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. > > Yes, I agree with this and it should be in the form of an fdt. This > means we need full qdev conversion. > > But I think cpuid is somewhere in the middle with respect to static vs. > dynamic. For instance, -cpu host is very dynamic in that you get very > difficult results on different systems. Likewise, because of kvm > filtering, even -cpu qemu64 can be dynamic. > > So if we didn't have filtering and -cpu host, I'd agree that it's > totally static but I think in the current state, it's dynamic. > >> 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. > > Yup, 100% in agreement as a long term goal. > >> 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. > > Yes, and we save some cpuid state in cpu. We just don't save all of it. > > Regards, > > Anthony Liguori >