From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Liu, Jinsong" Subject: RE: [PATCH 2/2] Expose tsc deadline timer cpuid to guest Date: Mon, 27 Feb 2012 16:05:08 +0000 Message-ID: References: <4F0482D6.8080705@web.de> <4F060961.9050002@web.de> <4F0A099C.5040805@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: Avi Kivity , Marcelo Tosatti , Alexey Zaytsev , kvm , "qemu-devel@nongnu.org" To: Jan Kiszka Return-path: Received: from mga03.intel.com ([143.182.124.21]:41101 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752488Ab2B0QFO convert rfc822-to-8bit (ORCPT ); Mon, 27 Feb 2012 11:05:14 -0500 In-Reply-To: <4F0A099C.5040805@web.de> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: 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? Thanks, Jinsong From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S234f-00047G-37 for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:05:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S234d-0006JI-Jb for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:05:16 -0500 Received: from mga03.intel.com ([143.182.124.21]:41064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S234d-0006Ix-Cc for qemu-devel@nongnu.org; Mon, 27 Feb 2012 11:05:15 -0500 From: "Liu, Jinsong" Date: Mon, 27 Feb 2012 16:05:08 +0000 Message-ID: References: <4F0482D6.8080705@web.de> <4F060961.9050002@web.de> <4F0A099C.5040805@web.de> In-Reply-To: <4F0A099C.5040805@web.de> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Jan Kiszka Cc: "qemu-devel@nongnu.org" , Marcelo Tosatti , Avi Kivity , kvm , Alexey Zaytsev 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.=20 >>>>>=20 >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> Thanks! understand this point ("They are part of the vm >> configuration which is not migrated but defined by starting qemu on >> the target host"). =20 >>=20 >> 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 =20 >>=20 >> if (kvmclock_enabled) { // the difference point between >> pc-0.13 vs. pc-0.14, related nothing to cpuid features. =20 >> kvmclock_create(); } } >=20 > 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. >=20 >>=20 >> 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 =20 >> * 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?=20 >> * logically cpuid features should better be controlled by cpu model, >> not by machine model.=20 >=20 > 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. >=20 in such case, it's '-cpu kvm64' who take effect to decide what cpuid featur= es 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 fe= atures to guest ... } Do I misunderstanding something? Thanks, Jinsong=