qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Thu, 21 Jan 2010 09:05:46 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (address@hidden) 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]