Add definitions for current cpu models..

This is a rework of the prior version which adds definitions for contemporary processors selected via -cpu<model>, as an alternative to the existing use of "-cpu qemu64" augmented with a series of feature flags.

The primary motivation was determination of a least common denominator within a given processor class to simplify guest migration. It is still possible to modify an arbitrary model via additional feature flags however the goal here was to make doing so unnecessary in typical usage. The other consideration was providing models names reflective of current processors. Both AMD and Intel have reviewed the models in terms of balancing generality of migration vs. excessive feature downgrade relative to released silicon.

Concerning the prior version of the patch, the proposed name used for a given model drew a fair amount of debate, the main concern being use of names as mnemonic as possible to the wisest group of users. Another suggestion was to use the vendor name of released silicon corresponding to a least common denominator CPU within the class, rational being doing so is more definitive of the intended functionality. However something like:

-cpu "Intel Core 2 Duo P9xxx"

probably isn't all that easy to remember nor type when selecting a Penryn class cpu. So I struck what I believe to be a reasonable compromise where the original x86_def_t.name was for the most part retained with the x86_def_t.model_id capturing the marketing name of the cpu being used as the least common denominator for the class. To make it easier for a user to associate a *.name with *.model_id, "-cpu ?" invoked rather as "-cpu ??" will append *.model_id to the generated table:

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

Quoted 4 lines · * Anthony Liguori ([email protected]) wrote:

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

What name will these users know? FWIW, it makes sense to me as it is.

Quoted 7 lines · Chris Wright

Quoted 4 lines · * Anthony Liguori ([email protected]) wrote:

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

What name will these users know? FWIW, it makes sense to me as it is.

2001, 2005, 2008, 2010 :-)

Quoted 5 lines · * Anthony Liguori ([email protected]) wrote:

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

What name will these users know? FWIW, it makes sense to me as it is.

thanks,
-chris

Quoted 8 lines · Chris Wright

Quoted 5 lines · * Anthony Liguori ([email protected]) wrote:

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

What name will these users know? FWIW, it makes sense to me as it is.

Whatever is in /proc/cpuinfo.

Quoted 11 lines · * Anthony Liguori ([email protected]) wrote:

Quoted 9 lines · Chris Wright

Quoted 6 lines · * Anthony Liguori ([email protected]) wrote:

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

Quoted 4 lines

Quoted 2 lines

What name will these users know? FWIW, it makes sense to me as it is.

Whatever is in /proc/cpuinfo.

That doesn't exactly generalize to families w/ similar cpuid features.

Intel(R) Xeon(R) {E,L,X}{74,55}**
Intel(R) Core(TM)2 {Duo,Quad,Extreme} ...

Quoted 13 lines · Chris Wright

Quoted 10 lines · * Anthony Liguori ([email protected]) wrote:

Quoted 8 lines · Chris Wright

Quoted 5 lines · * Anthony Liguori ([email protected]) wrote:

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

What name will these users know? FWIW, it makes sense to me as it is.

Whatever is in /proc/cpuinfo.

That doesn't exactly generalize to families w/ similar cpuid features.

Quoted 2 lines

Intel(R) Xeon(R) {E,L,X}{74,55}**
Intel(R) Core(TM)2 {Duo,Quad,Extreme} ...

Then we should key off of family and model.

So -cpu AMD_Family_10h

or something like that. At least that is discoverable by a user.

Quoted 7 lines · Chris Wright

Quoted 5 lines · * Anthony Liguori ([email protected]) wrote:

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

Quoted 2 lines

What name will these users know? FWIW, it makes sense to me as it is.

Whatever is in /proc/cpuinfo.

There is no mention of "Nehalem" in /proc/cpuinfo.

Quoted 7 lines · Chris Wright

Quoted 5 lines · * Anthony Liguori ([email protected]) wrote:

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

Quoted 2 lines

What name will these users know? FWIW, it makes sense to me as it is.

Whatever is in /proc/cpuinfo.

Quoted 8 lines · Anthony Liguori

Quoted 7 lines · Chris Wright

Quoted 5 lines · * Anthony Liguori ([email protected]) wrote:

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

Quoted 4 lines

Quoted 2 lines

What name will these users know? FWIW, it makes sense to me as it is.

Whatever is in /proc/cpuinfo.

    $ grep name /proc/cpuinfo
    model name  : Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Which is detailing that exact cpu vs. the class of which it is a member. So are you suggesting to map all instances of processors called out in /proc/cpuinfo into one of the three defined models? We can certainly do that however I was looking for a more terse and simplified solution at this level while deferring more ornate mapping schemes to management tools.

Still at the user facing CLI this doesn't strike me as the most friendly encoding of a -cpu <name>.

To be honest all possible naming schemes for '-cpu<name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'.

IMHO, we should just pick a concise naming scheme& document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner.

Daniel

To be honest all possible naming schemes for '-cpu <name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'.

IMHO, we should just pick a concise naming scheme & document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner.

Quoted 6 lines · * Daniel P. Berrange ([email protected]) wrote:

To be honest all possible naming schemes for '-cpu <name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'.

IMHO, we should just pick a concise naming scheme & document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner.

Heh, I completely agree, and was just saying the same thing to John earlier today. May as well be -cpu {foo,bar,baz} since the meaning for those command line options must be well-documented in the man page.

This is from an EVC kb article[1]:

Quoted 10 lines · Chris Wright

Quoted 6 lines · * Daniel P. Berrange ([email protected]) wrote:

To be honest all possible naming schemes for '-cpu <name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'.

IMHO, we should just pick a concise naming scheme & document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner.

Heh, I completely agree, and was just saying the same thing to John earlier today. May as well be -cpu {foo,bar,baz} since the meaning for those command line options must be well-documented in the man page.

I can appreciate the concern of wanting to get this as "correct" as possible. But ultimately we just need three unique tags which ideally have some relation to their associated architectures. The diatribes available from /proc/cpuinfo while generally accurate don't really offer any more of a clue to the model group, and in their unmodified form are rather unwieldy as command line flags.

Quoted 2 lines

This is from an EVC kb article[1]:

Here is a pointer to a more detailed version:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212

We probably should also add an option to dump out the full set of qemu-side cpuid flags for the benefit of users and upper level tools.

Quoted 16 lines · john cooper

Quoted 10 lines · Chris Wright

Quoted 7 lines · * Daniel P. Berrange ([email protected]) wrote:

To be honest all possible naming schemes for '-cpu <name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'. IMHO, we should just pick a concise naming scheme & document it. Given they are all equally unfriendly, the one that has consistency with vmware
naming seems like a mild winner.

Quoted 3 lines

Heh, I completely agree, and was just saying the same thing to John earlier today.  May as well be -cpu {foo,bar,baz} since the meaning for those command line options must be well-documented in the man page.

Quoted 8 lines

I can appreciate the concern of wanting to get this as "correct" as possible.  But ultimately we just need three unique tags which ideally have some relation to their associated architectures.  The diatribes available from /proc/cpuinfo while generally accurate don't really offer any more of a clue to the model group, and in their unmodified form are rather unwieldy as command line flags.

I agree. I'd underline that this patch is for migration purposes only, so you don't want to specify an exact CPU, but more like a class of CPUs. If you look into the available CPUID features in each CPU, you will find that there are only a few groups, with currently three for each vendor being a good guess.
/proc/cpuinfo just prints out marketing names, which have only a mild relationship to a feature-related technical CPU model. Maybe we can use a generation approach like the AMD Opteron ones for Intel, too. These G1/G2/G3 names are just arbitrary and have no roots within AMD.

I think that an exact CPU model specification is out of scope for this patch and maybe even for QEMU. One could create a database with CPU names and associated CPUID flags and provide an external tool to generate a QEMU command line out of this. Keeping this database up-to-date (especially for desktop CPU models) is a burden that the QEMU project does not want to bear.

Quoted 9 lines

Quoted 2 lines

This is from an EVC kb article[1]:

Here is a pointer to a more detailed version:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212

Quoted 3 lines

We probably should also add an option to dump out the full set of qemu-side cpuid flags for the benefit of users and upper level tools.

You mean like this one?
http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg01228.html
Resending this patch set is on my plan for next week. What is the state of this patch? Will it go in soon? Then I'd rebase my patch set on top of it.

Quoted 9 lines · Chris Wright

Quoted 7 lines · * Daniel P. Berrange ([email protected]) wrote:

To be honest all possible naming schemes for '-cpu<name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'.

IMHO, we should just pick a concise naming scheme& document it. Given they are all equally unfriendly, the one that has consistency with vmware naming seems like a mild winner.

Quoted 4 lines

Heh, I completely agree, and was just saying the same thing to John earlier today. May as well be -cpu {foo,bar,baz} since the meaning for those command line options must be well-documented in the man page.

I can appreciate the concern of wanting to get this as "correct" as possible.

Quoted 3 lines · john cooper

I can appreciate the concern of wanting to get this as "correct" as possible.

This is the root of the trouble. At the qemu layer, we try to focus on being correct.

Management tools are typically the layer that deals with being "correct".

A good compromise is making things user tunable which means that a downstream can make "correctness" decisions without forcing those decisions on upstream.

Quoted 11 lines · Anthony Liguori

Quoted 4 lines · john cooper

I can appreciate the concern of wanting to get this as "correct" as possible.

This is the root of the trouble. At the qemu layer, we try to focus on being correct.

Management tools are typically the layer that deals with being "correct".

Quoted 4 lines

A good compromise is making things user tunable which means that a downstream can make "correctness" decisions without forcing those decisions on upstream.

Conceptually I agree with such a malleable approach -- actually I prefer it. I thought however it was too much infrastructure to foist on the problem just to add a few more models into the mix.

The only reservation which comes to mind is that of logistics. This may ruffle the code some and impact others such as Andre who seem to have existing patches relative to the current structure. Anyone have strong objections to this approach before I have a look at an implementation?

Thanks,

-john

Quoted 9 lines · john cooper

Quoted 8 lines · Chris Wright

Quoted 7 lines · * Daniel P. Berrange ([email protected]) wrote:

To be honest all possible naming schemes for '-cpu<name>' are just as unfriendly as each other. The only user friendly option is '-cpu host'.

IMHO, we should just pick a concise naming scheme& document it. Given they are all equally unfriendly, the one that has consistency with vmware
naming seems like a mild winner.

Quoted 5 lines

Quoted 3 lines

Heh, I completely agree, and was just saying the same thing to John earlier today. May as well be -cpu {foo,bar,baz} since the meaning for those command line options must be well-documented in the man page.

I can appreciate the concern of wanting to get this as "correct" as possible.

This is the root of the trouble. At the qemu layer, we try to focus on being correct.

Management tools are typically the layer that deals with being "correct".

A good compromise is making things user tunable which means that a downstream can make "correctness" decisions without forcing those decisions on upstream.

In this case, the idea would be to introduce a new option, say something like -cpu-def. The syntax would be:

-cpu-def name=coreduo,level=10,family=6,model=14,stepping=8,features=+vme+mtrr+clflush+mca+sse3+monitor,xlevel=0x80000008,model_id="Genuine Intel(R) CPU T2600 @ 2.16GHz"

Which is not that exciting since it just lets you do -cpu coreduo in a much more complex way. However, if we take advantage of the current config support, you can have:

[cpu-def]
name=coreduo
level=10
family=6
model=14
stepping=8
features="+vme+mtrr+clflush+mca+sse3.."
model_id="Genuine Intel..."

And that can be stored in a config file. We should then parse /etc/qemu/target-<targetname>.conf by default. We'll move the current x86_defs table into this config file and then downstreams/users can define whatever compatibility classes they want.

With this feature, I'd be inclined to take "correct" compatibility classes like Nehalem as part of the default qemurc that we install because it's easily overridden by a user. It then becomes just a suggestion on our part verses a guarantee.

It should just be a matter of adding qemu_cpudefs_opts to qemu-config.[ch], taking a new command line that parses the argument via QemuOpts, then passing the parsed options to a target-specific function that then builds the table of supported cpus.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

x86 qemu64
x86 phenom
x86 core2duo
x86 kvm64

x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270

Quoted 3 lines

qemu-config.[ch], taking a new command line that parses the argument via QemuOpts, then passing the parsed options to a target-specific function that then builds the table of supported cpus.

It should just be a matter of adding qemu_cpudefs_opts to

Isn't the outcome of John's patches and these configs will be exactly the same? Since these cpu models won't ever change, there is no reason why not to hard code them. Adding configs or command lines is a good idea but it is more friendlier to have basic support to the common cpus. This is why qemu today offers: -cpu ?
x86 qemu64
x86 phenom
x86 core2duo
x86 kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270

So bottom line, my point is to have John's base + your configs. We need to keep also the check verb and the migration support for sending those.

btw: IMO we should deal with this complexity ourselves and save 99.9% of the users the need to define such models, don't ask this from a java programmer, he is running on a JVM :-)

Quoted 23 lines · Dor Laor

Quoted 3 lines

qemu-config.[ch], taking a new command line that parses the argument via QemuOpts, then passing the parsed options to a target-specific function that then builds the table of supported cpus.

It should just be a matter of adding qemu_cpudefs_opts to

Isn't the outcome of John's patches and these configs will be exactly the same? Since these cpu models won't ever change, there is no reason why not to hard code them. Adding configs or command lines is a good idea but it is more friendlier to have basic support to the common cpus. This is why qemu today offers: -cpu ?
x86 qemu64
x86 phenom
x86 core2duo
x86 kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270

Quoted 7 lines

So bottom line, my point is to have John's base + your configs. We need to keep also the check verb and the migration support for sending those.

btw: IMO we should deal with this complexity ourselves and save 99.9% of the users the need to define such models, don't ask this from a java programmer, he is running on a JVM :-)

I'm suggesting John's base should be implemented as a default config that gets installed by default in QEMU. The point is that a smart user (or a downstream) can modify this to suite their needs more appropriately.

Another way to look at this is that implementing a somewhat arbitrary policy within QEMU's .c files is something we should try to avoid. Implementing arbitrary policy in our default config file is a fine thing to do. Default configs are suggested configurations that are modifiable by a user. Something baked into QEMU is something that ought to work for

everyone in all circumstances.

Regards,

Anthony Liguori

Quoted 5 lines · Anthony Liguori

Another way to look at this is that implementing a somewhat arbitrary policy within QEMU's .c files is something we should try to avoid. Implementing arbitrary policy in our default config file is a fine thing to do. Default configs are suggested configurations that are modifiable by a user. Something baked into QEMU is something that ought to work for

If we get the models right, users and mgmt stacks won't need to define them. It seems like almost impossible task for us, mgmt stack/users won't do a better job, the opposite I guess. The configs are great, I have no argument against them, my case is that if we can pin down some definitions, its better live in the code, like the above models. It might even help to get the same cpus across the various vendors, otherwise we might end up with IBM's core2duo, RH's core2duo, Suse's,..

Quoted 7 lines · Dor Laor

Quoted 5 lines · Anthony Liguori

Another way to look at this is that implementing a somewhat arbitrary policy within QEMU's .c files is something we should try to avoid. Implementing arbitrary policy in our default config file is a fine thing to do. Default configs are suggested configurations that are modifiable by a user. Something baked into QEMU is something that ought to work for

Quoted 7 lines

If we get the models right, users and mgmt stacks won't need to define them. It seems like almost impossible task for us, mgmt stack/users won't do a better job, the opposite I guess. The configs are great, I have no argument against them, my case is that if we can pin down some definitions, its better live in the code, like the above models. It might even help to get the same cpus across the various vendors, otherwise we might end up with IBM's core2duo, RH's core2duo, Suse's,..

I agree. When looking at this thread and config file idea it feels a bit like "we have a hard time to agree on some sensible default cpu types, so lets make this configurable so we don't have to". Which is a bad thing IMHO.

cheers,
Gerd

x86 qemu64
x86 phenom
x86 core2duo
x86 kvm64

x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270

Quoted 4 lines · Dor Laor

x86 qemu64
x86 phenom
x86 core2duo
x86 kvm64

Quoted 8 lines

x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270

I think a really nice addition would be an autodetect option for those users (e.g. desktop) that know they do not want to migrate the guest to a lower-spec machine.

That option IMHO should just show up as identical to the host cpu, with the exception of features that are not supported in the guest.

Quoted 2 lines

That option IMHO should just show up as identical to the host cpu, with the exception of features that are not supported in the guest.

That's exactly what -cpu host is. IIRC it's the default now.

Quoted 15 lines · Arnd Bergmann

Quoted 13 lines · Dor Laor

x86 qemu64
x86 phenom
x86 core2duo
x86 kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270

Quoted 7 lines

I think a really nice addition would be an autodetect option for those users (e.g. desktop) that know they do not want to migrate the guest to a lower-spec machine.

That option IMHO should just show up as identical to the host cpu, with the exception of features that are not supported in the guest.

That's exactly what -cpu host is. IIRC it's the default now.

Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines · john cooper

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

Quoted 7 lines · Anthony Liguori

Quoted 6 lines · john cooper

    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)

Quoted 3 lines

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

kvm itself can modify flags exported from qemu to a guest.

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)

used by VmWare to describe their similar cpu models

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.

Quoted 3 lines

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.

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.

As before a cpu feature 'check' option is added which warns when feature flags (either implicit in a cpu model or explicit on the command line) would have otherwise been quietly unavailable to a guest:

    # qemu-system-x86_64 ... -cpu Nehalem,check
    warning: host cpuid 0000_0001 lacks requested flag 'sse4.2' [0x00100000]
    warning: host cpuid 0000_0001 lacks requested flag 'popcnt' [0x00800000]

Quoted 5 lines · john cooper

As before a cpu feature 'check' option is added which warns when feature flags (either implicit in a cpu model or explicit on the command line) would have otherwise been quietly unavailable to a guest:

Quoted 3 lines

    # qemu-system-x86_64 ... -cpu Nehalem,check
    warning: host cpuid 0000_0001 lacks requested flag 'sse4.2' [0x00100000]
    warning: host cpuid 0000_0001 lacks requested flag 'popcnt' [0x00800000]

That's a nice feature. Can we have a 'checkfail' option which refuses to run if a requested capability isn't available? Thanks.

I foresee wanting to iterate over the models and pick the latest one which a host supports - on the grounds that you have done the hard work of ensuring it is a reasonably good performer, while "probably" working on another host of similar capability when a new host is made available.

Quoted 5 lines

I foresee wanting to iterate over the models and pick the latest one which a host supports - on the grounds that you have done the hard work of ensuring it is a reasonably good performer, while "probably" working on another host of similar capability when a new host is made available.

That's a fairly close use case to that of safe migration which was one of the primary motivations to identify the models being discussed. Although presentation and administration of such was considered the domain of management tools.

Do you mean that more powerful management tools to support safe migration will maintain _their own_ processor model tables, and perform their calculations using their own tables instead of querying qemu, and therefore not have any need of qemu's built in table?

target-i386/helper.c +10 -0

+    {
+        .name = "Penryn",
+        .level = 2,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,   /* P6 */
+        .model = 2,
+        .stepping = 3,
+        .features = PPRO_FEATURES | 

target-i386/helper.c +11 -0

+    {
+        .name = "Nehalem",
+        .level = 2,
+        .vendor1 = CPUID_VENDOR_INTEL_1,
+        .vendor2 = CPUID_VENDOR_INTEL_2,
+        .vendor3 = CPUID_VENDOR_INTEL_3,
+        .family = 6,   /* P6 */
+        .model = 2,
+        .stepping = 3,
+        .features = PPRO_FEATURES | 
+            CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |    /* note 1 */