From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 2/2] Expose tsc deadline timer cpuid to guest Date: Mon, 27 Feb 2012 18:18:36 +0100 Message-ID: <4F4BBAEC.2040603@siemens.com> References: <4F0482D6.8080705@web.de> <4F060961.9050002@web.de> <4F0A099C.5040805@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Marcelo Tosatti , Alexey Zaytsev , kvm , "qemu-devel@nongnu.org" To: "Liu, Jinsong" Return-path: Received: from thoth.sbs.de ([192.35.17.2]:20773 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752804Ab2B0RS7 (ORCPT ); Mon, 27 Feb 2012 12:18:59 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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