[Top][All Lists]
[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
- [Qemu-devel] CPU type qemu64 breaks guest code,
Alexander Graf <=