qemu-devel
[Top][All Lists]
Advanced

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

Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3


From: Jamie Lokier
Subject: Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Date: Tue, 25 Sep 2007 16:54:23 +0100
User-agent: Mutt/1.4.1i

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

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.

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.

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.

-- Jamie




reply via email to

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