Re: [Qemu-devel] [PATCH v2 1/8] kvm: Set cpu_single_env only once

["Andreas Färber" <afaerber@suse.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 11.02.2012 15:24, schrieb Jan Kiszka:
> On 2012-02-11 15:12, Andreas Färber wrote:
>> Am 11.02.2012 15:02, schrieb Jan Kiszka:
>>> On 2012-02-11 14:59, Andreas Färber wrote:
>>>> Am 11.02.2012 14:35, schrieb Jan Kiszka:
>>>>> On 2012-02-11 14:21, Andreas Färber 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 
>>>> 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.
>> 
>>> Then the devices need to have access to a CPUState pointer,
>>> just as so far.
>> 
>> 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.

I already answered that above. Please join #qemu if you further want
to discuss that, for this thread seems to lead nowhere.

Andreas

> 
>> 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).
>> 
>> 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
> 


- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nü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
=jxwX
-----END PGP SIGNATURE-----