From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5bvW-0003B5-3h for qemu-devel@nongnu.org; Thu, 18 Jun 2015 11:40:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5bvS-00015w-S8 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 11:40:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5bvS-00015q-Mv for qemu-devel@nongnu.org; Thu, 18 Jun 2015 11:40:22 -0400 Date: Thu, 18 Jun 2015 17:40:18 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20150618154018.GA10217@potion.brq.redhat.com> References: <1434641064-8405-1-git-send-email-rkrcmar@redhat.com> <1434641064-8405-2-git-send-email-rkrcmar@redhat.com> <5582E3EA.2070407@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5582E3EA.2070407@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] target-i386: emulate CPUID level of real hardware List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: bsd@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com, rth@twiddle.net 2015-06-18 17:29+0200, Paolo Bonzini: > On 18/06/2015 17:24, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > W10 insider has a bug where it ignores CPUID level and interprets > > CPUID.(EAX=3D07H, ECX=3D0H) incorrectly, because CPUID in fact return= ed > > CPUID.(EAX=3D04H, ECX=3D0H); this resulted in execution of unsupport= ed > > instructions. > >=20 > > While it's a Windows bug, there is no reason to emulate incorrect lev= el; > > and amend xlevel while at it. > >=20 > > I have used http://instlatx64.atw.hu/ as a source of CPUID and checke= d > > that it matches Penryn Xeon X5472, Westmere Xeon W3520, SandyBridge > > i5-2540M, and Haswell i5-4670T. > >=20 > > kvm64 and qemu64 were bumped to 0xD to avoid similar problems. >=20 > This unfortunately has to be done only for new machine types. Old type= s > will remain buggy forever. Ah, ok, which machine type should I target, 2.4? And is patch 2 is only supposed to work with new machine types? Thanks.