From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once Date: Sat, 11 Feb 2012 15:24:21 +0100 Message-ID: <4F367A15.4050904@web.de> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4BF6D93436010534CDCFEADA" Cc: Blue Swirl , Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Avi Kivity , Paolo Bonzini To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:48258 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753308Ab2BKOYY (ORCPT ); Sat, 11 Feb 2012 09:24:24 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id 00B481C10378F for ; Sat, 11 Feb 2012 15:24:23 +0100 (CET) In-Reply-To: <4F36774D.4040405@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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--