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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
