From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states Date: Sun, 15 Nov 2009 16:02:32 +0100 Message-ID: <4B001808.2080503@web.de> References: <4AFB5123.7000301@web.de> <4AFB515D.1030202@web.de> <4B00087C.4060007@redhat.com> <4B000E71.3020901@web.de> <4B000FBB.3000600@redhat.com> <4B0010CD.7000406@web.de> <4B001253.9040207@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2AC35E60DB9E167928CDF52C" Cc: Marcelo Tosatti , kvm , Juan Quintela To: Avi Kivity Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:52175 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751752AbZKOPCb (ORCPT ); Sun, 15 Nov 2009 10:02:31 -0500 In-Reply-To: <4B001253.9040207@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2AC35E60DB9E167928CDF52C Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 11/15/2009 04:31 PM, Jan Kiszka wrote: >>>>> >>>>> Is there a reason why you add 11 between 9 and 10? We'll probably = see >>>>> another 11 when someone else adds the next state. >>>>> >>>>> >>>>> =20 >>>> Logical grouping ("/* KVM-related states */"). >>>> =20 >>> These aren't kvm-related, just not implemented in tcg yet. Nothing >>> kvmish about them - it's all architectural state. >>> =20 >> Most of them are KVM-specific. TCG don't have to deal with event >> re-injection due to host page faults etc. on first try. >> =20 >=20 > Right, tcg can do some things atomically. There's some non-kvm state i= n > there. >=20 >>>> If anyone once tries to >>>> add non-KVM stuff here just because it's version 12, it should be >>>> rejected. I don't think you have to sort VMSTATE entries by their >>>> version number. Am I right, Juan? >>>> >>>> =20 >>> I'm worried about something else - someone looking at the end, seeing= >>> version 10, and appending new state with version 11. >>> =20 >> Again, that's something proper review should catch (just like checking= >> for the right place when adding a new IOCTL to kvm.h). >> =20 >=20 > And we know how well that works. We should try to make things work by > default and leave the review to catch the really difficult things (like= > trailing whitespace). >=20 > At least add a comment at the end warning people that simple append wil= l > fail. >=20 Where should I add "/* next version to use: 13 */", and who will take care that this comment will also be kept up to date? The CPU vmstate is already ordered according to logical groups, just look at earlier field. Only recent KVM additions happened to create some version ordering as wel= l. Jan --------------enig2AC35E60DB9E167928CDF52C 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAksAGAsACgkQitSsb3rl5xSD0wCgugYCi9SYfN1axy1IWnsqSl8W LQcAn1nLokofmuCqOGXdc3lkQTxMm4Ri =8HpN -----END PGP SIGNATURE----- --------------enig2AC35E60DB9E167928CDF52C--