From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q20mu-0007oB-DS for qemu-devel@nongnu.org; Tue, 22 Mar 2011 08:34:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q20mt-00041e-2P for qemu-devel@nongnu.org; Tue, 22 Mar 2011 08:34:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q20ms-00041I-KJ for qemu-devel@nongnu.org; Tue, 22 Mar 2011 08:34:15 -0400 Message-ID: <4D88973F.3010609@redhat.com> Date: Tue, 22 Mar 2011 14:34:07 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] CPU type qemu64 breaks guest code References: <354E4FE9-104D-4A47-834A-FAE4868DF544@suse.de> In-Reply-To: <354E4FE9-104D-4A47-834A-FAE4868DF544@suse.de> 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: Alexander Graf Cc: Andre Przywara , Michael Matz , QEMU-devel List On 03/14/2011 04:13 PM, Alexander Graf wrote: > Hi guys, > > While I was off on vacation a pretty nasty bug emerged. It's our old friend the non-existent -cpu qemu64 CPU type. To refresh your memories, this is the definition of the default 64-bit CPU type in Qemu: > > { > .name = "qemu64", > .level = 4, > .vendor1 = CPUID_VENDOR_AMD_1, > .vendor2 = CPUID_VENDOR_AMD_2, > .vendor3 = CPUID_VENDOR_AMD_3, > .family = 6, > .model = 2, > .stepping = 3, > .features = PPRO_FEATURES | > CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA | > CPUID_PSE36, > .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_POPCNT, > .ext2_features = (PPRO_FEATURES& EXT2_FEATURE_MASK) | > CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX, > .ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM | > CPUID_EXT3_ABM | CPUID_EXT3_SSE4A, > .xlevel = 0x8000000A, > .model_id = "QEMU Virtual CPU version " QEMU_VERSION, > }, > > > Before I left, we already had weird build breakages where gcc simply abort()ed when running inside of KVM. This breakage has been tracked down to libgmp, which has this code (http://gmplib.org:8000/gmp-5.0/file/1ebe39104437/mpn/x86_64/fat/fat.c): > > if (strcmp (vendor_string, "GenuineIntel") == 0) > { > .... > } > else if (strcmp (vendor_string, "AuthenticAMD") == 0) > { > switch (family) > { > case 5: > case 6: > abort (); > break; > case 15: > /* CPUVEC_SETUP_athlon */ > break; > } > > The reasoning behind it is that for AMD, all 64-bit CPUs were family 15. > > This breakage is obviously pretty bad for guests running qemu and shows once again that deriving from real hardware is a bad idea. I guess the best way to move forward is to change the CPU type to something that actually exists in the real world - even if we have to strip off some features. Agree. > Any ideas? Comments? > The libgmp code should be fixed. If they want to take some specific action for specific processor families, that's fine, but abort()? -- error compiling committee.c: too many arguments to function