From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IaD4I-0005YV-OX for qemu-devel@nongnu.org; Tue, 25 Sep 2007 12:15:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IaD4H-0005Y9-Td for qemu-devel@nongnu.org; Tue, 25 Sep 2007 12:15:26 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IaD4H-0005Y1-NH for qemu-devel@nongnu.org; Tue, 25 Sep 2007 12:15:25 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IaD4H-00044j-2s for qemu-devel@nongnu.org; Tue, 25 Sep 2007 12:15:25 -0400 Message-ID: <46F93419.7030208@qumranet.com> Date: Tue, 25 Sep 2007 18:15:21 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3 References: <20070924174129.GA4507@karma.qumranet.com> <20070925084842.GA14221@karma.qumranet.com> <46F8CE52.3080502@qumranet.com> <1190711970.30193.15.camel@rapid> <46F8D577.3020306@qumranet.com> <46F8E5A2.30906@qumranet.com> <1190718562.30193.25.camel@rapid> <46F8F2B8.1080203@qumranet.com> <1190725664.13490.14.camel@jma4.dev.netgem.com> <20070925155423.GF28118@mail.shareable.org> In-Reply-To: <20070925155423.GF28118@mail.shareable.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: l_indien@magic.fr 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.