From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ia9AL-0006Rd-DT for qemu-devel@nongnu.org; Tue, 25 Sep 2007 08:05:25 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ia9AL-0006R6-0U for qemu-devel@nongnu.org; Tue, 25 Sep 2007 08:05:25 -0400 Received: from mx1.polytechnique.org ([129.104.30.34]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ia9AK-00009r-FB for qemu-devel@nongnu.org; Tue, 25 Sep 2007 08:05:24 -0400 Message-ID: <46F8F981.8020800@bellard.org> Date: Tue, 25 Sep 2007 14:05:21 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3 References: <20070905174530.GA3945@karma.qumranet.com> <20070910074005.GA26869@karma.qumranet.com> <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> In-Reply-To: <46F8F2B8.1080203@qumranet.com> 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: kvm-devel , "J. Mayer" Avi Kivity wrote: > J. Mayer wrote: > >>On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote: >> >> >>>Avi Kivity wrote: >>> >>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>I've got a remark about this: why this has to be added to the Qemu >>>>>code ? >>>>>Imho, all is needed is an implementation of the -cpu option for >>>>>x86/x86_64 target. Then, an external tool (even a shell script) can be >>>>>used to determine what is the host CPU if you want to select the exact >>>>>same CPU to be emulated in Qemu. It seems to me that trying to do so is >>>>>out of the scope of Qemu code and just add unneeded complexity. >>>>> >>>>> >>>>> >>>> >>>>Indeed for regular qemu this is useless. But it is useful for kqemu >>>>(for which there is support in mainline qemu), and for kvm (which we >>>>hope to merge one day). >>>> >>>> >>>> >>> >>>Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as >>>it can't trap cpuid in all circumstances. >>> >>>So this is mainly useful for kvm. I hope it will be applied regardless >>>of that, as there is agreement that kvm support should be merged. I'd >>>much rather pull the feature from qemu rather than carry it as an >>>additional patch. >>> >> >>Still I don't understand why it's usefull to put it inside the emulator >>and why: >># qemu -cpu `guess_host_cpu` >>would not do the work properly. Adding a specific case for '-cpu host' >>seems useless to me. >>And this way of doing potentially work for any family of emulated >>targets, without any modification in Qemu. If the string returned by >>'guess_host_cpu' is not recognized for the specific target you used it >>with, Qemu just stops telling it cannot find this CPU model, no more, no >>less. >> > > > It's a usability issue. I agree your suggestion would work, but I'd > like the default for kvm to be using the host cpu features, whereas > managed environments would specify some subset to enable live migration. > > >>The only case it could be interresting, imho, is if you do not allow the >>-cpu option in KVM case and force the cpu model instead using this >>function. This behavior does not seem to be great idea to me. >> > > > I think we can move the host cpu checks to kvm-specific code, since it > is not useful for kqemu. > > So, running qemu without any parameters would use host capabilities if > kvm is available and the default qemu cpu if not. The -cpu option can > be used to override this if necessary. Rectification: this is useful for kqemu too. I strongly suggest to look at kqemu.c:kqemu_update_cpuid() ! Moreover I believe that using the same CPU as host can be useful for pure emulation too, for example if code to do cache profiling is added. Regards, Fabrice.