Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

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

Anthony Liguori wrote:
> On 12/21/2009 02:28 AM, Dor Laor wrote:
>> John's new cpu definitions are the exact solution for this issue - all
>> users, whether using mgmt app or direct qemu (this is no user, this is
>> a developer/hacker/other, let's do not optimize this case) should use
>> the various 'real' cpu definitions like -cpu Merom | Nehalem | Penry |
>> Opteron G1, ....
> 
> Of course, the tricky part is at what level do you define these names. 
> For instance, do you do just Nehalem, or do you also do Nehalem,
> Nehalem-EP, Nehalem-EX?

>From a strict technical perspective I'd agree.  But this is
more an effort to define simplified discrete cpu models which
reasonably reflect deployed silicon.  An equal (if not greater)
motivation is to intentionally dumb-down portions of the
spectrum to simplify migration, albeit at the possible loss
of features provided by an individual cpu.

> Nehalem is really just a code name.  Would it be better to use core-i7?

I'd inquired whether marketing sanctioned names existed but
didn't receive anything conclusive.  The resulting monikers
at least are in common usage.
 
> I think the only two Fully Correct approachs are to support a very
> specific CPU (e.g. Xeon-X5270) or provide the ability to individually
> tweak cpu flags.

We have the ability today to pass an exhaustive list of
feature flags.  Offering a sprawling list of fine tuned
models is possible although somewhat cumbersome, and
doesn't address the need to collapse ranges into a least
common denominator for the benefit of migration.

> For instance, Xeon-X5570 should be a least common denominator for
> Nehalem processors.  It's probably better for users too.  It's easier
> for them to answer "do I have anything older than a Xeon-X5570" than to
> ask "do I have any Woodcrest class processors".

I'm not particularly biased to a naming scheme.  Although the
generic labels avoid suggesting a specific instance of a cpu
class which is helpful in this context.

Engaging the vendors with this scheme was also somewhat
of a sanity check to assure it reflects commercially deployed
vs. development silicon.

-john 


-- 
john.cooper@redhat.com