Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..

[john cooper <john.cooper@redhat.com>]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>> On 01/18/2010 10:45 AM, john cooper wrote:
>>>     x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
>>>     x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
>>>     x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
>>>     x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
>>>     x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
>>>     x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
>> I'm very much against having -cpu Nehalem.  The whole point of this is 
>> to make things easier for a user and for most of the users I've 
>> encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,...
> 
> When I saw that table just now, I had no idea whether Nehalem is newer
> and more advanced than Penryn, or the other way around.  I also have
> no idea if "Core i7" is newer than "Core 2 Duo" or not.

I can appreciate the argument above, however the goal was
choosing names with some basis in reality.  These were
recommended by our contacts within Intel, are used by VmWare
to describe their similar cpu models, and arguably have fallen
to defacto usage as evidenced by such sources as:

    http://en.wikipedia.org/wiki/Conroe_(microprocessor)
    http://en.wikipedia.org/wiki/Penryn_(microprocessor)
    http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)

I suspect whatever we choose of reasonable length as a model
tag for "-cpu" some further detail is going to be required.
That was the motivation to augment the table as above with
an instance of a LCD for that associated class.
 
> I'm not a typical user: I know quite a lot about x86 architecture;
> I just haven't kept up to date enough to know the code/model names.
> Typical users will know less about them.

Understood.  One thought I had to further clarify what is going
on under the hood was to dump the cpuid flags for each model as
part of (or in addition to) the above table.  But this seems a
bit extreme and kvm itself can modify flags exported from qemu
to a guest.

-john

-- 
john.cooper@redhat.com