From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49537)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XMcSD-0004Eo-G5
	for qemu-devel@nongnu.org; Wed, 27 Aug 2014 08:36:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XMcS7-0005Hs-BJ
	for qemu-devel@nongnu.org; Wed, 27 Aug 2014 08:35:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:63970)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XMcS6-0005Hi-UT
	for qemu-devel@nongnu.org; Wed, 27 Aug 2014 08:35:51 -0400
Message-ID: <53FDD09C.4040208@redhat.com>
Date: Wed, 27 Aug 2014 14:35:40 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20140826071427.1672.48119.stgit@PASHA-ISP>
	<20140826071503.1672.32964.stgit@PASHA-ISP>
	<53FC5ADE.8030306@redhat.com>
	<002401cfc1f0$b5aefe50$210cfaf0$@Dovgaluk@ispras.ru>
In-Reply-To: <002401cfc1f0$b5aefe50$210cfaf0$@Dovgaluk@ispras.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 06/12] kvmvapic: fixing loading vmstate
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: Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru>, qemu-devel@nongnu.org
Cc: zealot351@gmail.com, maria.klimushenkova@ispras.ru

Il 27/08/2014 14:16, Pavel Dovgaluk ha scritto:
>> > Can you use a vm_change_state_handler, or a QEMU_CLOCK_VIRTUAL timer
>> > with expiration time in the past (e.g. at time zero) to run the sync
>> > code as soon as possible?  Then you can preserve the current migration
>> > format and avoid using the invalid APIC state.
> Does this method guarantee, that nobody (like other timers) will access
> APIC between loading the vmstate and invocation of the timer?

Hmm, probably not.  The bug would not be other timers accessing the
APIC, because that would also call apic_sync_vapic and the only effect
would be an extra useless synchronization.  The bug would happen if the
APIC is accessed by the CPU before the timer has the occasion to run.

However, a vm_change_state_handler should work.  It runs before VCPUs
are started.

Paolo