From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMhsR-0004ey-If for qemu-devel@nongnu.org; Mon, 21 Dec 2009 08:00:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMhsM-0004Z0-Di for qemu-devel@nongnu.org; Mon, 21 Dec 2009 08:00:42 -0500 Received: from [199.232.76.173] (port=48602 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMhsM-0004Ym-Ab for qemu-devel@nongnu.org; Mon, 21 Dec 2009 08:00:38 -0500 Received: from tx2ehsobe004.messaging.microsoft.com ([65.55.88.14]:45860 helo=TX2EHSOBE007.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1NMhsL-0007YK-Dc for qemu-devel@nongnu.org; Mon, 21 Dec 2009 08:00:37 -0500 Message-ID: <4B2F7133.8030500@amd.com> Date: Mon, 21 Dec 2009 13:59:31 +0100 From: Andre Przywara 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> In-Reply-To: <4B2F58BC.30307@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 , Alexander Graf , "Michael S. Tsirkin" Avi Kivity wrote: > On 12/20/2009 07:59 PM, Anthony Liguori wrote: >> Gleb Natapov wrote: >>> Windows is a mystery box, so we can speculate as much as we want >>> about it. >>> If you don't like something just say "it may break Windows" :) Losing >>> activation does sound like an issue too. >> >> Downgrading seems more likely to cause problems. Considering running >> mplayer in a guest. If it detects SSE3 in one host and migrate to >> another host that doesn't have SSE3, you'll be running an instruction >> stream that uses instructions the processor doesn't support resulting >> in the application faulting due to an illegal operation. >> > > Migration needs preparation beforehand. You can't take two random hosts > with two random qemu flag sets and expect it to work. > >> 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. >... >> 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. Regards, Andre. 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). -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448 3567 12 ----to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Andrew Bowd; Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632