[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] kvmclock: clarify usage of cpu_clean_all_dirty
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH] kvmclock: clarify usage of cpu_clean_all_dirty |
Date: |
Tue, 16 Sep 2014 18:22:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 |
Il 16/09/2014 18:07, Marcelo Tosatti ha scritto:
>> > The cpu_synchronize_all_states() call in kvmclock_vm_state_change() is
>> > needed to make env->tsc up to date with the value on the source, right?
> Its there to make sure the pair
>
> env->tsc, s->clock = data.clock
>
> are relative to point close in time.
Ok. But why are they not close in time?
Could we have the opposite situation where env->tsc is loaded a long
time _after_ s->clock, and something breaks?
Also, there is no reason to do kvmclock_current_nsec() during normal
execution of the VM. Is the s->clock sent by the source ever good
across migration, and could the source send kvmclock_current_nsec()
instead of whatever KVM_GET_CLOCK returns?
I don't understand this code very well, but it seems to me that the
migration handling and VM state change handler are mixed up...
Paolo
>> > But if the synchronize_all_states+clean_all_dirty pair runs on the
>> > source, why is the cpu_synchronize_all_states() call in
>> > qemu_savevm_state_complete() not enough? It runs even later than
>> > kvmclock_vm_state_change.
> Because of the "pair of time values" explanation above.
Re: [Qemu-devel] [PATCH] kvmclock: clarify usage of cpu_clean_all_dirty, Marcelo Tosatti, 2014/09/16