From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKHcW-00082w-B5 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:34:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKHcR-0007zw-R2 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:34:16 -0500 Received: from [199.232.76.173] (port=45160 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKHcR-0007zl-II for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:34:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39347) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKHcQ-0000uO-N6 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:34:10 -0500 Date: Mon, 14 Dec 2009 22:31:25 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20091214203125.GH6150@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B269D99.8080404@codemonkey.ws> 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 , avi@redhat.com On Mon, Dec 14, 2009 at 02:18:33PM -0600, 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. This won't help with kernels <2.6.32 though. I guess we can switch default vendor to Intel, this likely has some other side effects. > 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. > > Regards, > > Anthony Liguori It's a tradeoff, but yes. We also need more sanity checks and management commands giving management tools to understand whether emulating guest CPU X on host CPU Y is safe/possible, and which guests this might break. -- MST