From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2 1/8] kvm: Set cpu_single_env only once Date: Sat, 11 Feb 2012 14:35:24 +0100 Message-ID: <4F366E9C.8080808@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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig695126792704ABCC81742CBB" Cc: Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Return-path: In-Reply-To: <4F366B74.1000501@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig695126792704ABCC81742CBB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-02-11 14:21, Andreas F=C3=A4rber wrote: > Am 11.02.2012 14:07, schrieb Jan Kiszka: >> On 2012-02-11 14:06, Andreas F=C3=A4rber wrote: >>> Am 11.02.2012 13:43, schrieb Jan Kiszka: >>>> On 2012-02-11 12:49, Andreas F=C3=A4rber wrote: >>>>> Am 11.02.2012 12:25, schrieb Blue Swirl: >>>>>> I think using cpu_single_env is an indication of a >>>>>> problem, like poor code, layering violation or poor API >>>>>> (vmport). What is your use case? >>>>> >>>>> I couldn't spot any in this series. Jan, note that any new >>>>> use of env or cpu_single_env will need to be redone when we >>>>> convert to QOM CPU. >>> >>>> cpu_single_env should have nothing to do with QOM. >>> >>> It does, cf. my patch series: Current CPU*State is being embedded >>> in the QOM object and most future code outside TCG will use a >=20 > Let me stress this: >=20 >>> CPU rather than CPUState pointer. >=20 >>> The reason is that CPUState is totally target-specific and does >>> not belong in common code. >=20 >> So are the devices that depend on a current CPU pointer. You will >> have to provide something equivalent. >=20 > CPU base class v3: > http://patchwork.ozlabs.org/patch/139284/ (v4 coming up) >=20 > 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. Do you plan accessors for registers? And a service to return the CPU object associated with the execution context? Jan --------------enig695126792704ABCC81742CBB 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/ iEYEARECAAYFAk82bpwACgkQitSsb3rl5xTTrQCg1w+7J5eAOvUkWlbU6nYTppX3 maEAoIusYJPgyqfjsTh5l4eSAIG9oLnv =80wM -----END PGP SIGNATURE----- --------------enig695126792704ABCC81742CBB--