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

[Michael Matz]

Hi,

On Mon, 21 Mar 2011, Andre Przywara wrote:

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

Mimicking as a really existing CPU would trigger exactly those code 
paths that are triggered when that same code is running on real hardware.
If such hypothetical problems were real they would occur for non-emulated 
hardware already.  But they don't.

> >        else if (strcmp (vendor_string, "AuthenticAMD") == 0)
> >            switch (family)
> >              {
> >                 case 5:
> >                 case 6:
> >                     abort ();
> >
> > 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.

Not really.  The above is for the x86_64 code paths, i.e. 64bit code.  
There never were, and there never will be, AMD processors capable of 
running 64bit code that have family 5 or 6.  The abort can't ever trigger 
on hardware or correctly emulated hardware.

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

It's not about need.  It's about tuning and expectations.  gmp wants to 
tune itself according to the hardware it runs on, hence it switches on the 
vendor and family/model.  And in order not to have to handle combinations 
that can't exist in the real world (which seems sane to me) the aborts 
where put in place.  Now there's something to be said about being lenient 
in what you accept, but it's not wrong to be strict.

> I found that there is no valid combination for both Intel and AMD.

Of course not.  Why should there?  The FMS combination obviously can't 
exist independend of the (claimed) vendor.  Trying to go for one FMS that 
fits all is going to fail, how could it be different?


Ciao,
Michael.