From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46719 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pg2Gu-00075s-Qp for qemu-devel@nongnu.org; Thu, 20 Jan 2011 16:42:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pg2Gt-00048a-B8 for qemu-devel@nongnu.org; Thu, 20 Jan 2011 16:42:24 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:54864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pg2Gs-000489-VO for qemu-devel@nongnu.org; Thu, 20 Jan 2011 16:42:23 -0500 Message-ID: <4D38AC3C.20607@web.de> Date: Thu, 20 Jan 2011 22:42:20 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state References: <4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de> <4D2B8662.9060909@web.de> <4D2C60FB.7030009@linux.vnet.ibm.com> <4D2D80ED.8030405@redhat.com> <4D2D82EE.20002@siemens.com> <4D35A39A.8000801@siemens.com> <4D35ABF8.9050700@linux.vnet.ibm.com> <4D35B521.3090601@siemens.com> <4D35B6DD.1020005@linux.vnet.ibm.com> <4D3717E7.3010105@linux.vnet.ibm.com> <4D38017D.2020401@siemens.com> <4D388EE8.3000004@linux.vnet.ibm.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62FCFCB832BA6B73EDC9AE80" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: "kvm@vger.kernel.org" , Glauber Costa , Marcelo Tosatti , Markus Armbruster , "qemu-devel@nongnu.org" , Anthony Liguori , Avi Kivity This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62FCFCB832BA6B73EDC9AE80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-01-20 21:02, Blue Swirl wrote: > I think KVMState was designed to match KVM ioctl interface: all stuff > that is needed for talking to KVM or received from KVM are there. But > I think this shouldn't be a design driver. Agreed. The nice cleanup would probably be the complete assimilation of KVMState by something bigger of comparable scope. If a machine was brought up with KVM support, every device that refers to this machine (as it is supposed to become part of it) should be able to use KVM services in order to accelerate its model. >=20 > If the only pieces of kvm_state that are needed by the devices are > irqchip_in_kernel, pit_in_kernel and many_ioeventfds, the problem of > passing kvm_state to devices becomes very different. Each of these are > just single bits, affecting only a few devices. Perhaps they could be > device properties which the board level sets when KVM is used? Forget about the static capabilities for now. The core of kvm_state are handles that enable you to use KVM services and maybe state fields that have machine scope (unless we find more local homes like a memory object). Those need to be accessible by the kvm layer when servicing requests of components that are related to that very same machine. Jan --------------enig62FCFCB832BA6B73EDC9AE80 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.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk04rDwACgkQitSsb3rl5xRN8ACgux1/U0GXOhKCgPsxC/pFejjB gYwAoNTxn/tGQOE7LB+MRfBibyFJdbeN =X3Qx -----END PGP SIGNATURE----- --------------enig62FCFCB832BA6B73EDC9AE80--