From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMPiQ-0008Fh-5s for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:37:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMPiL-00084b-EB for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:37:09 -0500 Received: from [199.232.76.173] (port=34789 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMPiL-00084T-7r for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:37:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38492) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMPiK-0008Tm-R0 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 12:37:05 -0500 Date: Sun, 20 Dec 2009 19:37:02 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20091220173702.GC21163@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2162E312-0110-42E1-A391-D75A6F013554@suse.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org, Avi Kivity , "Michael S. Tsirkin" On Sun, Dec 20, 2009 at 06:29:11PM +0100, Alexander Graf wrote: > > On 20.12.2009, at 18:23, Gleb Natapov wrote: > > > On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote: > >> On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote: > >>> > >>> On 20.12.2009, at 17:56, Michael S. Tsirkin wrote: > >>> > >>>> On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote: > >>>>> On 12/20/2009 05:51 PM, Michael S. Tsirkin 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. > >>>>>>> > >>>>>> This seems very aggressive. Can't we whitelist features that we know > >>>>>> about? Further, doesn't KVM already do this? > >>>>>> > >>>>>> > >>>>> > >>>>> It does, but without -cpuid host you're stuck with qemu64 (kvm.ko > >>>>> doesn't add features userspace didn't request). > >>>> > >>>> Hmm, then, shouldn't either kvm or qemu mask features that we do not > >>>> emulate well enough to make windows not crash? > >>> > >>> -cpu host does that already, no? > >>> > >>> Alex > >> > >> I expected so, but Avi here seems to say windows will crash if you > >> use a new CPU with it ... > >> > > Windows _may_ crash if you'll _upgrade_ your _host_ CPU. > > Uh. It may lose activation I guess. But apart from that I can't see how it'd break as long as you don't expect loadvm to work. > > Anybody mind to go into a bit more detail here? :-) > 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. -- Gleb.