From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMdcz-0007sE-E3 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 03:28:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMdcs-0007q7-42 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 03:28:27 -0500 Received: from [199.232.76.173] (port=34515 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMdcr-0007pw-CF for qemu-devel@nongnu.org; Mon, 21 Dec 2009 03:28:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1025) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMdcq-0006n2-U0 for qemu-devel@nongnu.org; Mon, 21 Dec 2009 03:28:21 -0500 Message-ID: <4B2F31B1.6040403@redhat.com> Date: Mon, 21 Dec 2009 10:28:33 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <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> <20091221074355.GU4490@redhat.com> In-Reply-To: <20091221074355.GU4490@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: "Michael S. Tsirkin" , John Cooper , qemu-devel@nongnu.org, Alexander Graf , Avi Kivity On 12/21/2009 09:43 AM, Gleb Natapov wrote: > On Sun, Dec 20, 2009 at 11:59:43AM -0600, 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. >> >> 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. >> >> This is a classic problem with live migration. You can detect this >> scenario and potentially block the migration, but honestly, how >> likely is it that any given guest is using an obscure feature? This >> is a classic management tool problem and the solution usually is a >> set of heuristics depending on how conservative the target audience >> is. >> > I am confused. We explicitly not talking about migration, why bring it > here? We are talking about casual user who can't care less about > migration, but he upgrades his home computer and Windows VM stops > working for him. John's new cpu definitions are the exact solution for this issue - all users, whether using mgmt app or direct qemu (this is no user, this is a developer/hacker/other, let's do not optimize this case) should use the various 'real' cpu definitions like -cpu Merom | Nehalem | Penry | Opteron G1, .... Qemu will check the required cpuid of the cpu model on the host and refuse to load otherwise. When moving to this model, migration can be simplified too since there are fewer combination, and one can choose performance over migration flexibility and wise versa. Due to the above check, the destination qemu won't load if the host does not support its cpu model. > > -- > Gleb. > >