qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] CPU type qemu64 breaks guest code


From: Alexander Graf
Subject: [Qemu-devel] CPU type qemu64 breaks guest code
Date: Mon, 14 Mar 2011 15:13:59 +0100

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.

Any ideas? Comments?


Alex




reply via email to

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