[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] CPU type qemu64 breaks guest code

From: Avi Kivity
Subject: Re: [Qemu-devel] CPU type qemu64 breaks guest code
Date: Tue, 22 Mar 2011 14:34:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9

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 |
         .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_POPCNT,
         .ext2_features = (PPRO_FEATURES&  EXT2_FEATURE_MASK) |
         .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 

       if (strcmp (vendor_string, "GenuineIntel") == 0)
       else if (strcmp (vendor_string, "AuthenticAMD") == 0)
           switch (family)
                case 5:
                case 6:
                    abort ();
                case 15:
                   /* CPUVEC_SETUP_athlon */

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]