From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S24E2-0002ZU-2x for qemu-devel@nongnu.org; Mon, 27 Feb 2012 12:19:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S24Dv-00021P-Ug for qemu-devel@nongnu.org; Mon, 27 Feb 2012 12:19:01 -0500 Received: from thoth.sbs.de ([192.35.17.2]:21152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S24Dv-0001yM-Jk for qemu-devel@nongnu.org; Mon, 27 Feb 2012 12:18:55 -0500 Message-ID: <4F4BBAEC.2040603@siemens.com> Date: Mon, 27 Feb 2012 18:18:36 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F0482D6.8080705@web.de> <4F060961.9050002@web.de> <4F0A099C.5040805@web.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Liu, Jinsong" Cc: "qemu-devel@nongnu.org" , Marcelo Tosatti , Avi Kivity , kvm , Alexey Zaytsev On 2012-02-27 17:05, Liu, Jinsong wrote: > Jan Kiszka wrote: >> On 2012-01-07 19:23, Liu, Jinsong wrote: >>> Jan Kiszka wrote: >>>> On 2012-01-05 18:07, Liu, Jinsong wrote: >>>>>> Sorry, it remains bogus to expose the tsc deadline timer feature >>>>>> on machines < pc-1.1. That's just like we introduced kvmclock >>>>>> only to pc-0.14 onward. The reason is that guest OSes so far >>>>>> running on qemu-1.0 or older without deadline timer support must >>>>>> not find that feature when being migrated to a host with qemu-1.1 >>>>>> in pc-1.0 compat mode. Yes, the user can explicitly disable it, >>>>>> but that is not the idea of legacy machine models. They should >>>>>> provide the very same environment that older qemu versions >>>>>> offered. >>>>>> >>>>> >>>>> Not quite clear about this point. >>>>> Per my understanding, if a kvm guest running on an older qemu >>>>> without tsc deadline timer support, >>>>> then after migrate, the guest would still cannot find tsc deadline >>>>> feature, no matter older or newer host/qemu/pc-xx it migrate to. >>>> >>>> What should prevent this? The feature flags are not part of the >>>> vmstate. They are part of the vm configuration which is not migrated >>>> but defined by starting qemu on the target host. >>>> >>> >>> Thanks! understand this point ("They are part of the vm >>> configuration which is not migrated but defined by starting qemu on >>> the target host"). >>> >>> But kvmclock example still cannot satisfy the purpose "guest running >>> on old qemu/pc-0.13 without kvmclock support must not find kvmclock >>> feature when being migrated to a host with new qemu/pc-0.13 compat >>> mode". After migration, guest can possibily find kvmclock >>> feature CPUID.0x40000001.KVM_FEATURE_CLOCKSOURCE: pc_init1(..., >>> kvmclock_enabled) { pc_cpus_init(cpu_model); // the point to >>> decide and expose cpuid features to guest >>> >>> if (kvmclock_enabled) { // the difference point between >>> pc-0.13 vs. pc-0.14, related nothing to cpuid features. >>> kvmclock_create(); } } >> >> Right, not a perfect example: the cpuid feature is not influenced by >> this mechanism, only the fact if a kvmclock device (for save/restore) >> should be created. I guess we ignored this back then, only focusing on >> the more obvious issue of the addition device. >> >>> >>> Seems currently there is no good way to satisfy "guest running on >>> old qemu/pc-xx without feature A support must not find feature A >>> when being migrated to a host with new qemu/pc-xx compat mode", i.e. >>> considering >>> * if running with '-cpu host' then migrate; >>> * each time we add a new cpuid feature it need add one or more new >>> machine model? is it necessary to bind pc-xx with cpuid feature? >>> * logically cpuid features should better be controlled by cpu model, >>> not by machine model. >> >> The compatibility machines define the possible cpu models. If I select > > How does machine define possible cpu models? > cpu model defined by qemu option '-cpu ...', while machine model defined by '-machine ...' > >> pc-0.14, e.g. -cpu kvm64 should not give me features that 0.14 was not >> exposing. >> > > in such case, it's '-cpu kvm64' who take effect to decide what cpuid features would exposed to guest, not '-machine pc-0.14'. > > IMO, what our patch need to do is to expose a cpuid feature to guest (CPUID.01H:ECX.TSC_Deadline[bit 24]), it decided by cpu model, not machine model: > pc_init1(..., cpu_model, ...) > { > pc_cpus_init(cpu_model); // this is the whole logic exposing cpuid features to guest > ... > } > > Do I misunderstanding something? My point is that qemu-version-A [-cpu whatever] should provide the same VM as qemu-version-B -machine pc-A [-cpu whatever] specifically if you leave out the cpu specification. So the compat machine could establish a feature mask (e.g. append some "-tsc_deadline" in this case). But, indeed, we need a new channel for this. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux