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

[Paolo Bonzini <pbonzini@redhat.com>]

On 02/11/2012 03:12 PM, Andreas Färber wrote:
> 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
> 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).

Hmm, now I'm not even sure what I want that Andreas referred to. :)

I definitely would like CPUState pointers to be changed into link 
properties, but that's not related to what Jan is doing here with 
cpu_single_env.  Each LAPIC refers to a CPU, and that would become a 
link property indeed.  But here we're using cpu_single_env to find out 
which LAPIC is being read.  It's the other direction.

Relying on thread-local cpu_single_env means that you restrict LAPIC 
memory reads to run in VCPU thread context, and this makes sense anyway. 
  The only case of MMIO running in iothread context is Xen, but Xen 
always keeps the LAPIC in the hypervisor.

Also, I think that having a view of CPUs in QOM is laudable, but I don't 
understand why that means you need to remove first_cpu / cpu_single_env.

Finally, CPU_COMMON members may be referenced from TCG-generated code, 
how do you plan to move them and still keep the TLBs at small offsets 
within CPUState?  Perhaps we need a drawing of the situation before and 
after the QOMization of CPUs.

Paolo