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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux