On Thu, Dec 03, 2009 at 07:21:01PM +0100, Jan Kiszka wrote: > Merge 8e2c5ec2f6 forgot to restore some qemu-kvm-specific hooks in > cpu_post_load. mp_state was readded later on, but tsc was missing, > breaking the guest timing after resume. Also, reset of halt was dropped > which is obviously required for in-kernel irqchip. > > Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > --- > > This solves "Problem 1" on my list. > > BTW, this patch just made me realize that the TSC MSR belongs to the > list states that should not be written back unconditionally. Upstream > does this currently, qemu-kvm not (at the price one more kvm-specific > hook into generic code). Unlike the other states we discussed, this one > is not "fixable" in the kernel. So I tend to think there is a real need > for my write-back scope abstraction - which would also be able to handle > the other states cleanly, both in upstream and here. > > target-i386/machine.c | 10 +++++++++- > 1 files changed, 9 insertions(+), 1 deletions(-) > > diff --git a/target-i386/machine.c b/target-i386/machine.c > index 6bd447f..9ac477b 100644 > --- a/target-i386/machine.c > +++ b/target-i386/machine.c > @@ -366,7 +366,15 @@ static int cpu_post_load(void *opaque, int version_id) > hw_breakpoint_insert(env, i); > > tlb_flush(env, 1); > - kvm_load_mpstate(env); > + > + if (kvm_enabled()) { > + /* when in-kernel irqchip is used, env->halted causes deadlock > + because no userspace IRQs will ever clear this flag */ > + env->halted = 0; > + That is strange. env->halted should be used only for "info cpus" output in case of in-kernel irqchip. Can you see where it hangs? > + kvm_load_tsc(env); > + kvm_load_mpstate(env); > + } > > return 0; > } -- Gleb. -- 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