From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwDsH-0002aO-VM for qemu-devel@nongnu.org; Sat, 11 Feb 2012 09:24:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RwDsG-00082s-Ba for qemu-devel@nongnu.org; Sat, 11 Feb 2012 09:24:25 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:54996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwDsF-00082l-Tj for qemu-devel@nongnu.org; Sat, 11 Feb 2012 09:24:24 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate03.web.de (Postfix) with ESMTP id E90851B10481D for ; Sat, 11 Feb 2012 15:24:22 +0100 (CET) Message-ID: <4F367A15.4050904@web.de> Date: Sat, 11 Feb 2012 15:24:21 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F363DB2.3080908@web.de> <4F3655E7.3090905@suse.de> <4F36626D.7020109@web.de> <4F3667BC.9060306@suse.de> <4F36680B.7090400@web.de> <4F366B74.1000501@suse.de> <4F366E9C.8080808@web.de> <4F36742F.2050600@suse.de> <4F36750A.5060304@web.de> <4F36774D.4040405@suse.de> In-Reply-To: <4F36774D.4040405@suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4BF6D93436010534CDCFEADA" Subject: Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4BF6D93436010534CDCFEADA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-02-11 15:12, Andreas F=C3=A4rber wrote: > Am 11.02.2012 15:02, schrieb Jan Kiszka: >> On 2012-02-11 14:59, Andreas F=C3=A4rber wrote: >>> Am 11.02.2012 14:35, schrieb Jan Kiszka: >>>> On 2012-02-11 14:21, Andreas F=C3=A4rber wrote: >>>>> CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ >>>>> (v4 coming up) >>>>> >>>>> That doesn't prevent target-specific devices. Although Paolo >>>>> does want that to change wrt properties. >>> >>>> This patch doesn't explain yet what shall happen to >>>> cpu_single_env and CPUState accesses from target-specific >>>> devices. >>> >>> True. We can't change them before all targets are converted. So >>> far I have 3/14 and still some review comments to work in. >>> >>> Another patch in that series uses a macro=20 >>> s/ENV_GET_OBJECT/ENV_GET_CPU/ to go from CPUState -> CPU while >>> we convert targets. >>> >>> Depending on our taste, cpu_single_env might become >>> cpu_single_cpu, single_cpu or cpu_single. >>> >>>> Do you plan accessors for registers? >>> >>> No, registers are in target-specific ARMCPU, S390CPU, MIPSCPU, >>> etc. and their CPU*State. It would be possible to have static >>> inline accessors but so far I've seen no need. >=20 >> Then the devices need to have access to a CPUState pointer, just as >> so far. >=20 > Yes and no. They can have any target-specific pointer they want, just > as before. But no global first_cpu / cpu_single_env pointer - that's If you want to drop first_cpu, you need to provide a for_each_cpu iterating service instead. And cpu_single_env can only be obsoleted if I/O access handlers can otherwise query the triggering CPU. > replaced by CPU pointers, through which members of derived classes can > be accessed (which did not work for CPUState due to CPU_COMMON members > being at target-specific offset in the middle). >=20 > There's nothing wrong with your patch per se, just that it may need to > get refactored some time soonish. We need to be aware of it so that we > don't create merge conflicts for Anthony. There can't be logical merge conflicts as the no fundamentally new requirements are introduced with this series. And we have no code proposal seen yet to address them already for the existing use cases. Jan --------------enig4BF6D93436010534CDCFEADA 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/ iEYEARECAAYFAk82ehUACgkQitSsb3rl5xQJmgCfWpl4uzhHajd0CgwNh3LllWye rYoAn09nkyydvUvdhJa+QDlWvM5M/ItV =4R/z -----END PGP SIGNATURE----- --------------enig4BF6D93436010534CDCFEADA--