From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Subject: Re: [PATCH v2 1/8] kvm: Set cpu_single_env only once Date: Sat, 11 Feb 2012 15:49:48 +0100 Message-ID: <4F36800C.2080002@suse.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> <4F367A15.4050904@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Blue Swirl , Avi Kivity , Paolo Bonzini To: Jan Kiszka Return-path: In-Reply-To: <4F367A15.4050904@web.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 11.02.2012 15:24, schrieb Jan Kiszka: > 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) >>>>>>=20 >>>>>> 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=20 >>>>> cpu_single_env and CPUState accesses from target-specific=20 >>>>> 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=20 >>>> 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=20 >>>> 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. >>=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 >=20 > If you want to drop first_cpu, you need to provide a for_each_cpu=20 > iterating service instead. And cpu_single_env can only be obsoleted > if I/O access handlers can otherwise query the triggering CPU. I already answered that above. Please join #qemu if you further want to discuss that, for this thread seems to lead nowhere. Andreas >=20 >> 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. >=20 > There can't be logical merge conflicts as the no fundamentally new=20 > requirements are introduced with this series. And we have no code=20 > proposal seen yet to address them already for the existing use > cases. >=20 > Jan >=20 - --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPNoALAAoJEPou0S0+fgE/OHAQALK7X6v9nA0A4tZ8umD4Ak8p DkyHX9N0pkv8Jc9y06WWLCzsgCQJFxPKp0n0mpWHhG96mWryez+Cd8x00W9wJJWx A15beRV80jwpDWlkNMtnQ+T9kvVamUsL3a090Bgcb662EkCpfR5UtjDlrYBM7X7f C/ejV31NYnFIXM5F2TcsURrXZ7GRXNeSRsoXrt2WoCBhFkf+DBek8ejEsYcFS6q0 lrqoggHTVKRZuGbBIJ9yS3/L/pf6gWDOv1ZyUAHfAUeWt2rD3NxNFHHFLbrl3d47 k5Yev4acZOTe6ozgvK3qWcrvA2t42BmKTCA7FqLKg2057szll277wKHf0K2xqlvs oYTbSk4t9IWI4StBFevgVDM0kaXg6OAGKiDDP8PRrBI3YzJajLL6zkDVitA5Hp0N LPryOYwhI+KtO3Too7R919UDZIoZ+pg2Mm+L1/1IuneB8Ar1MeiPwU0zXLYGiDVx ZrMzjhhbYJn+PPC8FxI9gnaPkLVkZzSfcXkpA1RXLZdpkjdmt4rwA0KfFNB000DU fag3rAGTdcvT8O58K2FXYAWe8VFqA979VHWxsTOLrVX3rL9Xbi63SUfvz/joMryO mZMYsJ/NGHd5IVYdWP0kBdxuXRtFUaqHnp7PFnwj0IXtnV13csgB2nN+HN5wJULs A855i5ibqUahcKGej48W =3DjxwX -----END PGP SIGNATURE-----