From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56260)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XTvWP-0001Ch-Ii
	for qemu-devel@nongnu.org; Tue, 16 Sep 2014 12:22:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XTvWJ-0006w9-9K
	for qemu-devel@nongnu.org; Tue, 16 Sep 2014 12:22:29 -0400
Received: from mx1.redhat.com ([209.132.183.28]:56311)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XTvWJ-0006uc-2R
	for qemu-devel@nongnu.org; Tue, 16 Sep 2014 12:22:23 -0400
Message-ID: <541863B7.5060705@redhat.com>
Date: Tue, 16 Sep 2014 18:22:15 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20140916151437.GA27819@amt.cnet> <54185A58.2010105@redhat.com>
	<20140916155526.GB29476@amt.cnet> <54185F5C.60906@redhat.com>
	<20140916160735.GB30753@amt.cnet>
In-Reply-To: <20140916160735.GB30753@amt.cnet>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [PATCH] kvmclock: clarify usage of
	cpu_clean_all_dirty
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>

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.