[Top][All Lists]

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

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

From: Andre Przywara
Subject: [Qemu-devel] Re: CPU type qemu64 breaks guest code
Date: Mon, 21 Mar 2011 22:46:32 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101020 Thunderbird/3.0.9

On 03/14/2011 03: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,
> ...

Well, yes, this is strange, and a different CPU model mimicking some really existing CPU would be better. But in my experience this opens up a can of worms, since a different family will trigger a lot of other nasty code that was silent before. Although I think that eventually we will not get around it doing so, but we should use a lot of testing before triggering tons of regressions. What about the kvm64 CPU model? Back then I used quite some testing to find a model which runs pretty well, so I came up with 15/6/1, which seemed to be relatively sane. We could try copying this F/M/S over to qemu64, I suppose with emulation the issues are easier to fix than in KVM.

Another idea I think I already posted some time ago was to make kvm64 the new default if KVM is enabled. This wouldn't solve the above issue for TCG of course, but would make further development easier, since we would have a better separation between KVM and TCG and could tweak each independently.

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

I guess that should be fixed there, as it is obviously nonsense. I haven't check what they actually need that family 6 does not provide, if it is long mode, then this bit should be checked.

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

I found that there is no valid combination for both Intel and AMD. We had to go to family 15, and it seems that there is no F/M/S combination that were both a valid K8 and a Pentium4 processor. The 15/6/1 mentioned before was the closest match I could find.

Summarizing I would suggest:
1) Make kvm64 the new default model if KVM is used. Maybe we could tie
   this to the qemu-0.15 machine type.
2) Test as many OSes as possible whether they show strange behavior.
   In my experience we could catch most of the stuff with just booting
   the system, with Linux "-kernel vmlinuz" suffices (without a rootfs).
3) If we are happy with that, tweak the qemu64 model to those values,
4) Write some note somewhere to let users know what they could do to
   fix problems that rise due to the new model.

I can easily send patches and will try to contribute to testing, if that plan sounds OK.

Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany

reply via email to

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