Jamie Lokier wrote:
Jocelyn Mayer wrote:
Well, it may be needed to integrate the "-cpu host" option.
But I think it's a really bad idea that running qemu without the -cpu
option would not act the same on different host. When I want to test
qemu with the same command line, I want it to behave exactly the same,
whatever the host I'm running on, like any other tool. Think about gcc,
for example, if you launch it without option, it compiles for a generic
CPU. If you want to tune the generated code, even for the host you're
running on, you have to use -mcpu/-march/-mtune. Using one command line
always have gives the same result.
Then, my opinion is that running qemu without any -cpu option should
always use a default target.
A major feature of qemu is reproducible behaviour. This is especially
important when resuming snapshots or booting pre-installed images for
testing things.
A major feature of kvm/kqemu is performance. But not always
performance at the expense of reproducibility. Sometimes you want to
use kvm/kqemu to make qemu as fast as possible while still behaving
the same with some image.
Where someone wants performance to have precedence, it's easy enough
to advise "use -cpu host" for that.
Where someone wants performance, but reproducibility to have
precedence, it would be more awkward to have to advise "use -cpu
list,of,common,features".
Or maybe "-cpu baseline" or some other neutral word.
I think reproducibility is something which needs to be working by
default. This is because people make images before they decide to
move them to other hosts, and often before they would consider at all
issues about host differences, and making images is sometimes a lot of
work. Images should be portable among hosts by default.
But, if we say that the default is a baseline CPU, and there's a "-cpu
host" option to maximise performance, then we have to decide what
features the baseline CPU has. Obviously a 386 isn't very useful for
emulation any more - many OSes won't run on it.
The baseline cpu should be whatever qemu supports today.
Then, if we change our mind about the default baseline CPU, then we've
lost reproducibility for old images anyway.
That's an argument for storing the emulated CPU features in images.
That's another thread -- I want memory size and network configuration in
there too :)
If that's done, then for image portability among hosts, it is not so
important that the default CPU have only the features which
are native to every host. Instead, the critical thing is simply that
it has only features which are either native or can be emulated on
every host. E.g. TSC is in this category.
Qemu is used to support three different user classes which have
different requirements. Developers want reproducibility and control, so
-cpu baseline should be the default for them. Home users want speed to
run Windows or test distros, so -cpu host and kvm should be the default
for them. Managed deployments want something in between, so they'd
specify -cpu feature,feature and won't care about the default.
We can make it a ./configure option. I suspect distros will want to set
-cpu host as default as their users primarily care about speed.
--
Any sufficiently difficult bug is indistinguishable from a feature.
