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

[Jamie Lokier]

john cooper wrote:
> 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)

(Aside: I can confirm they haven't fallen into de facto usage anywhere
in my vicinity :-) I wonder if the contact within Intel are living in
a bit of a bubble where these names are more familiar than the outside
world.)

I think we can all agree that there is no point looking for a familiar
-cpu naming scheme because there aren't any familiar and meaningful names
these days.

> used by VmWare to describe their similar cpu models

If the same names are being used, I see some merit in qemu's list
matching VMware's cpu models *exactly* (in capabilities, not id
strings), to aid migration from VMware.  Is that feasible?  Do they
match already?

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

Here's another idea.

It would be nice if qemu could tell the user which of the built-in
-cpu choices is the most featureful subset of their own host.  With
-cpu host implemented, finding that is probably quite easy.

Users with multiple hosts will get a better feel for what the -cpu
names mean that way, probably better than any documentation would give
them, because they probably have not much idea what CPU families they
have anyway.  (cat /proc/cpuinfo doesn't clarify, as I found).

And it would give a simple, effective, quick indication of what they
must choose if they want an VM image that runs on more than one of
their hosts without a management tool.

-- Jamie