From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMIQ9-0005Lt-PD for qemu-devel@nongnu.org; Sun, 20 Dec 2009 04:49:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMIQ4-0005Gq-LS for qemu-devel@nongnu.org; Sun, 20 Dec 2009 04:49:49 -0500 Received: from [199.232.76.173] (port=44403 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMIQ4-0005Gh-I2 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 04:49:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29823) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMIQ3-00018L-Vu for qemu-devel@nongnu.org; Sun, 20 Dec 2009 04:49:44 -0500 Message-ID: <4B2DF334.6030208@redhat.com> Date: Sun, 20 Dec 2009 11:49:40 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <20091214193541.GA6150@redhat.com> <4B269596.1050103@codemonkey.ws> <20091214194432.GC6150@redhat.com> <4B2698A9.9090107@codemonkey.ws> <20091214200002.GA27769@redhat.com> <4B2699BB.1090302@codemonkey.ws> <20091214201049.GD6150@redhat.com> <4B269D99.8080404@codemonkey.ws> In-Reply-To: <4B269D99.8080404@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: qemu-devel@nongnu.org, Gleb Natapov , "Michael S. Tsirkin" On 12/14/2009 10:18 PM, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> This might help 32 bit guests, but not guests with 64 bit >> kernel and 32 bit userspace (my case) because all 64 bit >> CPUs advertise syscall bit in cpuid. Thus 64 bit guests >> do not seem to even bother checking this bit: >> AMD + 64 bit -> syscall. > > Okay, I don't see a great option other than migrating the vendor_id > string. > That's not strictly necessary since the guest cannot change the vendor string; all the user has to do is to launch both guests with explicit vendor ids. Of course that imposes more on the user (or the management application). > Otherwise, cross vendor migration will not work by default. Maybe > that's not a problem but if so, we really should change the default > cpu model to be much more aggressive about exposing host features. Maybe we should make -cpu host the default. That will give the best performance for casual users, more testing for newer features, and will force management apps to treat migration much more seriously. The downside is that casual users upgrading their machines might experience issues with Windows. Feature compatibility is not just about migration. -- error compiling committee.c: too many arguments to function