From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMQ4N-00078L-K3 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:59:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMQ4I-000751-V2 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:59:51 -0500 Received: from [199.232.76.173] (port=60400 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMQ4I-00074q-Lb for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:59:46 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:45382) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMQ4I-0005ed-3W for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:59:46 -0500 Received: by ywh1 with SMTP id 1so4251892ywh.18 for ; Sun, 20 Dec 2009 09:59:45 -0800 (PST) Message-ID: <4B2E660F.1050703@codemonkey.ws> Date: Sun, 20 Dec 2009 11:59:43 -0600 From: Anthony Liguori 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> In-Reply-To: <20091220173702.GC21163@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: Gleb Natapov Cc: Avi Kivity , "Michael S. Tsirkin" , Alexander Graf , qemu-devel@nongnu.org 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. Regards, Anthony Liguori