Am 28.01.2013 14:50, schrieb Gleb Natapov: > On Fri, Jan 25, 2013 at 04:55:29PM +0100, Andreas Färber wrote: >> Since commit 20d695a9254c1b086a456d3b79a3c311236643ba (kvm: Pass >> CPUState to kvm_arch_*) CPUArchState is no longer needed. >> >> Allows to change qemu_kvm_eat_signals() argument as well. >> >> Signed-off-by: Andreas Färber <afaerber@xxxxxxx> > Reviewed-by: Gleb Natapov <gleb@xxxxxxxxxx> Thanks, applied to qom-cpu: https://github.com/afaerber/qemu-cpu/commits/qom-cpu Background was: https://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg03087.html <<< [...] qemu_init_vcpu() still operates on CPUArchState and thus cannot be moved into CPUClass yet. The reason is that cpus.c:qemu_kvm_cpu_thread_fn sets cpu_single_env, and I do not see a solution for that - suggestions or patches welcome. However, I see that kvm-all.c:kvm_on_sigbus_vcpu() can be switched to CPUState now, so that cpus.c:qemu_kvm_eat_signals() can be changed to CPUState, used from cpus.c:qemu_kvm_wait_io_event(). But cpus.c:cpu_thread_is_idle() still uses env->halted, which is blocked by the search for an acceptable solution to flush the TLB at CPUState level (exec.c:cpu_common_post_load()). >>> A less elegant but working solution is on my qom-cpu-8 branch (based off qom-cpu-next): I introduced a void *env_ptr CPUState field. While potentially opening a can of worms I wanted to avoid, it allows us to defer finding a solution to the target_ulong-dependent TLB some more. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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
