From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMO6Y-0003Oz-0O for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:53:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMO6T-0003Lp-5S for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:53:57 -0500 Received: from [199.232.76.173] (port=55026 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMO6S-0003Lc-Th for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:53:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25652) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMO6R-0003Xq-V9 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:53:52 -0500 Date: Sun, 20 Dec 2009 17:51:01 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20091220155101.GB31257@redhat.com> 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> <4B2DF334.6030208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2DF334.6030208@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Gleb Natapov , qemu-devel@nongnu.org On Sun, Dec 20, 2009 at 11:49:40AM +0200, Avi Kivity wrote: > 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. This seems very aggressive. Can't we whitelist features that we know about? Further, doesn't KVM already do this? -- MST