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

[Andre Przywara <andre.przywara@amd.com>]

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
> (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.

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
> features.

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,
    too.
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