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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
