From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: CPU vendor in KVM Date: Sat, 04 May 2013 10:05:31 +0200 Message-ID: <5184C14B.9040100@web.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2OLDGKQAKRAOEQSGKHLSW" Cc: qemu-devel@nongnu.org, kvm To: =?UTF-8?B?IuadjuaYpeWlhyA8QXJ0aHVyIENodW5xaSBMaT4i?= Return-path: Received: from mout.web.de ([212.227.17.12]:64452 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754507Ab3EDIFe (ORCPT ); Sat, 4 May 2013 04:05:34 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OLDGKQAKRAOEQSGKHLSW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2013-05-04 09:50, =E6=9D=8E=E6=98=A5=E5=A5=87 wrote= : > Hi Jan and All, > I find that when enable KVM with qemu, vendor ID of simulated CPU will = be > set the same as host, but other features such as level, family, model, > stepping are not changed. This may bring out a confusing result, the > simulated CPU has a vendor name of "GenuineIntel" but with family numbe= r > "16". >=20 > I disabled the related code in function cpu_x86_find_by_name: > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > index e2302d8..df0e82e 100644 > --- a/target-i386/cpu.c > +++ b/target-i386/cpu.c > @@ -1295,7 +1295,8 @@ static int cpu_x86_find_by_name(x86_def_t > *x86_cpu_def, const char *name) > * KVM's sysenter/syscall emulation in compatibility mode = and > * when doing cross vendor migration > */ > - if (kvm_enabled()) { > + //if (kvm_enabled()) { > + if (0) { > uint32_t ebx =3D 0, ecx =3D 0, edx =3D 0; > host_cpuid(0, 0, NULL, &ebx, &ecx, &edx); > x86_cpu_vendor_words2str(x86_cpu_def->vendor, ebx, edx= , > ecx); >=20 > And the information of CPU remains consistent and the VM runs OK, even > though with nested environment. >=20 > Why should qemu set simulated cpu's vendor same as the host in KVM > environment? The reason (and a way out) is given in the comment above the cited code. Jan ------enig2OLDGKQAKRAOEQSGKHLSW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGEwUsACgkQitSsb3rl5xRQlgCg4M70oAT1mEoScLNnyV0JDggt i2YAni6ROATOXc2EwkU+nTEVJbuRr4uu =zTr8 -----END PGP SIGNATURE----- ------enig2OLDGKQAKRAOEQSGKHLSW--