From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMkuV-00081W-Mv for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:15:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMkuQ-0007wd-KH for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:15:03 -0500 Received: from [199.232.76.173] (port=36844 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMkuQ-0007wU-HG for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:14:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4979) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMkuQ-0002Vr-7P for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:14:58 -0500 Message-ID: <4B2F9EFD.1040700@redhat.com> Date: Mon, 21 Dec 2009 18:14:53 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <20091214201049.GD6150@redhat.com> <4B269D99.8080404@codemonkey.ws> <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> <20091220165612.GC31257@redhat.com> <20091220171822.GD31257@redhat.com> <20091220172341.GB21163@redhat.com> <2162E312-0110-42E1-A391-D75A6F013554@suse.de> <20091220173702.GC21163@redhat.com> <4B2E660F.1050703@codemonkey.ws> <4B2F58BC.30307@redhat.com> <4B2F7133.8030500@amd.com> In-Reply-To: <4B2F7133.8030500@amd.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: Andre Przywara Cc: qemu-devel@nongnu.org, Gleb Natapov , Alexander Graf , "Michael S. Tsirkin" On 12/21/2009 02:59 PM, Andre Przywara wrote: >> >>> KVM's cpuid filter doesn't help here because it won't attempt to >>> mask things like sse3. It would be insane to emulate sse3 too. >> >> It does expose sse3 support (called pni in Linux IIRC). Not sure if >> qemu masks it, but the information is there. > > What about using -cpu kvm64? > This has SSE3 as well as CMPXCHG16, both are available in all VMX/SVM > capable machines (as far as I could find out) and in TCG. > This gives a pretty descent base without loosing many relevant > performance features. Sure. This gives more performance to users and preserves compatibility pretty well. The disadvantage is that the baseline will recede as more processor features are introduced. >> ... >>> This is a classic management tool problem and the solution usually >>> is a set of heuristics depending on how conservative the target >>> audience is. >> >> Right. My concern is with casual users upgrading their machine, not >> enterprise users who should be protected by their tools. > Then what about fixing the CPUID bits to those returned by the KVM > module the first time the guest is started? Later you would only use > those bits (which may have been cropped) for later restarts of the > same guest. If you only upgrade your machine, then there should be no > problems. First, even an upgrade may cause loss of cpuid bits (moving to a different vendor). Second, where do you store those bits? > > P.S. What feature bits do we talk about? > Maybe we should group them and use aliases for those. > SS_S_E3 and SSE4.x come to mind, are any other bits really relevant? > (Or do they justify the pain we have when propagating them?) > Then we would only need: Athlon64, Core2, Nehalem (and maybe Phenom). Future bits too, for example AVX. -- error compiling committee.c: too many arguments to function