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 <[email protected]>
> ---
>
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
