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

[Avi Kivity <avi@redhat.com>]

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