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

[Alexander Graf]

On 21.03.2011, at 22:46, Andre Przywara wrote:

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

Michael (IIRC) already tried that one, but the libgmp guys refuse to change the 
code here, as is works on real hardware...

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

I love that plan! Please make sure to provide the current qemu64 type when -M 
pc-0.14 is selected, so people can still choose the old type for migration.


Alex