From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMNmc-00052K-5d for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:33:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMNmX-0004yv-FN for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:33:21 -0500 Received: from [199.232.76.173] (port=53018 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMNmX-0004yq-Bx for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:33:17 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:40433) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMNmX-0007QH-28 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:33:17 -0500 Received: by ywh1 with SMTP id 1so4199999ywh.18 for ; Sun, 20 Dec 2009 07:33:16 -0800 (PST) Message-ID: <4B2E43BA.7030404@codemonkey.ws> Date: Sun, 20 Dec 2009 09:33:14 -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> <4B2DF334.6030208@redhat.com> <4B2E3943.9020802@codemonkey.ws> <4B2E3AC5.3040200@redhat.com> In-Reply-To: <4B2E3AC5.3040200@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: Avi Kivity Cc: qemu-devel@nongnu.org, Gleb Natapov , "Michael S. Tsirkin" Avi Kivity wrote: > On 12/20/2009 04:48 PM, Anthony Liguori wrote: >> Avi Kivity wrote: >>> >>> 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. >> >> Yes, I'd much rather do this than mucking with vendor_id. If we're >> going to give up on cross vendor migration by default, I think we >> should go for best performance. > > If we do this, we need to advertise it clearly: > > - casual (non-management-app-using) users will start seeing problems > with Windows guests unless they change their command lines Assuming their migrating across different CPU types. > - management apps really have to take cpuid into account now > (previously, it was just a good idea) Yes. I think we probably should have a management app writers guide that spells out all of the quirks and best practices that we often discuss here and assume that management app writers are going to follow. Sounds like a good thing to live in the proposes docs directory :-) Regards, Anthony Liguori