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. > >> And a service to return the CPU object associated with the >> execution context? > > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
