From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKHwa-0002tU-8D for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:55:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKHwV-0002p8-1X for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:54:59 -0500 Received: from [199.232.76.173] (port=39764 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKHwU-0002ow-M3 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:54:54 -0500 Received: from mail-iw0-f197.google.com ([209.85.223.197]:58829) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKHwT-0002mr-Uk for qemu-devel@nongnu.org; Mon, 14 Dec 2009 15:54:54 -0500 Received: by iwn35 with SMTP id 35so2277309iwn.4 for ; Mon, 14 Dec 2009 12:54:52 -0800 (PST) Message-ID: <4B26A619.7070503@codemonkey.ws> Date: Mon, 14 Dec 2009 14:54:49 -0600 From: Anthony Liguori 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> <20091214203125.GH6150@redhat.com> In-Reply-To: <20091214203125.GH6150@redhat.com> 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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Gleb Natapov , avi@redhat.com 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. >> 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