From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MR6A7-0000CX-Ja
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 11:12:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MR6A3-0000Aa-13
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 11:12:51 -0400
Received: from [199.232.76.173] (port=54777 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MR6A2-0000AR-O7
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 11:12:46 -0400
Received: from mail2.shareable.org ([80.68.89.115]:53210)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1MR6A2-0003vT-3j
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 11:12:46 -0400
Date: Wed, 15 Jul 2009 16:12:34 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] CPUID feature bits not saved with migration
Message-ID: <20090715151234.GA28724@shareable.org>
References: <4A5DD0B0.7070700@amd.com> <4A5DE9E5.2080809@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A5DE9E5.2080809@codemonkey.ws>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Andre Przywara <andre.przywara@amd.com>, qemu-devel@nongnu.org

Anthony Liguori wrote:
> It's unclear what to do about -cpu host.  If we did migrate cpuid 
> values, then -cpu would effectively be ignored after an incoming migration.

The new host might not support all the cpuid features of the old host,
whether by -cpu host or explicit cpuid.  What happens then?

For changing cpuid when migrating, as you might like to do with -cpu
host for performance, is reboot-during-migrate useful?  It would make
sure all disk state is committed to the image files asynchronously
while the machine continues to run (just like normal migration), and
at the last moment transfers control and the machine sees a reboot,
permitting devices changes including cpuid change.

CPU hotplug could be used for cpuid change in theory, but I doubt if
any guests or guest apps would handle it well.

-- Jamie