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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On 2012-02-11 14:21, Andreas Färber wrote:
> Am 11.02.2012 14:07, schrieb Jan Kiszka:
>> On 2012-02-11 14:06, Andreas Färber wrote:
>>> Am 11.02.2012 13:43, schrieb Jan Kiszka:
>>>> On 2012-02-11 12:49, Andreas Färber 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
> 
> Let me stress this:
> 
>>> CPU rather than CPUState pointer.
> 
>>> The reason is that CPUState is totally target-specific and does
>>> not belong in common code.
> 
>> So are the devices that depend on a current CPU pointer. You will
>> have to provide something equivalent.
> 
> 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. Do you plan accessors
for registers? And a service to return the CPU object associated with
the execution context?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]