From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKIEF-0000WB-J2 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:13:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKIEB-0000VV-RS for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:13:15 -0500 Received: from [199.232.76.173] (port=54471 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKIEB-0000VS-O8 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:13:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2967) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKIEB-00040V-9B for qemu-devel@nongnu.org; Mon, 14 Dec 2009 16:13:11 -0500 Date: Mon, 14 Dec 2009 23:10:25 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20091214211024.GD6100@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> <20091214203125.GH6150@redhat.com> <4B26A619.7070503@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B26A619.7070503@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:54:49PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> 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. >> > > That's a kernel bug. If we think it effects a lot of users, we should > introduce a CAP such that we can detect this in userspace and fail > gracefully. Not emulating feature host CPU does not have is a kernel bug? Okay ... Yes, almost no one runs 2.6.32 yet. >>> 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. >>> >> 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. >> > > I'd like to see Avi weigh in as historically, he's been one of the > strongest advocates of a default migration policy of maximum > compatibility. Personally, I think cross vendor migration is extremely > uncommon in production and I would strongly recommend against it. > > My own experience has been that hardware homogeneity is pretty common in > deployments, particularly in the processor space. There's such a > different between Nehalem and non-Nehalem class processors that you > really can't run the same workloads across the two without seeing a > significant impact. > > So I'd actually be in favor of changing the default cpu to something > that exposes a lot more of the underlying processor features. I think > increased performance would be better for most consumers vs. increased > migration flexibility. > > Then again, I'm certainly bias based on being employed by a hardware > vendor :-) > > Regards, > > Anthony Liguori