From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSrmP-0005No-Na for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:47:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSrmL-0005Ib-4Y for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:47:57 -0500 Received: from [199.232.76.173] (port=40653 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSrmK-0005IU-SR for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:47:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59092) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSrmK-0003zX-7b for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:47:52 -0500 Date: Thu, 7 Jan 2010 12:47:38 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20100107124738.GB9028@redhat.com> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B45D642.3070009@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: kvm-devel , Gleb Natapov , "Michael S. Tsirkin" , John Cooper , dlaor@redhat.com, Alexander Graf , qemu-devel@nongnu.org On Thu, Jan 07, 2010 at 02:40:34PM +0200, 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. > > 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. With the introduction of the new -device spport, there's no need to replay hotplug events in order any more. Instead just use static PCI addresses when starting the guest, and the same addresses after migration. You could argue that QEMU should preserve the addressing automatically during migration, but apps need to do it manually already to keep addreses stable across power-offs, so doing it manually across migration too is no extra burden. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|