On 01/25/2010 03:08 AM, Dor Laor wrote:
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 :-)
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