From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rk0EY-0008If-0c for qemu-devel@nongnu.org; Sun, 08 Jan 2012 16:24:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rk0EW-0000aJ-TP for qemu-devel@nongnu.org; Sun, 08 Jan 2012 16:24:53 -0500 Received: from fmmailgate05.web.de ([217.72.192.243]:54686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rk0EW-0000aB-H2 for qemu-devel@nongnu.org; Sun, 08 Jan 2012 16:24:52 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate05.web.de (Postfix) with ESMTP id 253F668D5860 for ; Sun, 8 Jan 2012 22:24:51 +0100 (CET) Message-ID: <4F0A099C.5040805@web.de> Date: Sun, 08 Jan 2012 22:24:44 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F0482D6.8080705@web.de> <4F060961.9050002@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F39FB46E74908999B1A28F0" 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F39FB46E74908999B1A28F0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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,=20 >>> 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 > Thanks! understand this point ("They are part of the vm configuration w= hich is not migrated but defined by starting qemu on the target host"). >=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)=20 > { > pc_cpus_init(cpu_model); // the point to decide and expose cpuid= features to guest >=20 > if (kvmclock_enabled) { // the difference point between pc-0= =2E13 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. >=20 > Seems currently there is no good way to satisfy "guest running on old q= emu/pc-xx without feature A support must not find feature A when being mi= grated 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 mach= ine model? is it necessary to bind pc-xx with cpuid feature? > * logically cpuid features should better be controlled by cpu model, no= t by machine model. The compatibility machines define the possible cpu models. If I select pc-0.14, e.g. -cpu kvm64 should not give me features that 0.14 was not exposing. Jan --------------enig0F39FB46E74908999B1A28F0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8KCaAACgkQitSsb3rl5xSNngCgt/h6dJpFj/ZtQVGqWNiTnwxr 4aoAnA+bB5I++/apEJNfsEjKJcfvcT9O =g9bg -----END PGP SIGNATURE----- --------------enig0F39FB46E74908999B1A28F0--