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 15:02:50 +0100 Message-ID: <4F36750A.5060304@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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig92C84FD4F0BC4D3854DF7125" 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: <4F36742F.2050600@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) --------------enig92C84FD4F0BC4D3854DF7125 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 >> This patch doesn't explain yet what shall happen to cpu_single_env >> and CPUState accesses from target-specific devices. >=20 > 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. >=20 > Another patch in that series uses a macro > s/ENV_GET_OBJECT/ENV_GET_CPU/ to go from CPUState -> CPU while we > convert targets. >=20 > Depending on our taste, cpu_single_env might become cpu_single_cpu, > single_cpu or cpu_single. >=20 >> Do you plan accessors for registers? >=20 > 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. Then the devices need to have access to a CPUState pointer, just as so fa= r. >=20 >> And a service to return the CPU object associated with the >> execution context? >=20 > What do you mean by execution context? TLS? The modelling of the state > is pretty orthogonal to how/where we store it. I mean "Where come this I/O access from?" and "am I running over some VCPU thread?". This questions need to be answered in target-specific device models and some parts of cpus.c (the latter is one motivation for this patch). Jan --------------enig92C84FD4F0BC4D3854DF7125 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/ iEYEARECAAYFAk82dQoACgkQitSsb3rl5xR0lwCeJmaH8EzPZ52rAytNY7secOOK e2sAoNICm1UaZQJDd/6kn5edoOpkx4vp =rYKH -----END PGP SIGNATURE----- --------------enig92C84FD4F0BC4D3854DF7125--