From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7AnL-0005W7-SH for qemu-devel@nongnu.org; Tue, 15 Jul 2014 18:02:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X7AnH-0007js-Ci for qemu-devel@nongnu.org; Tue, 15 Jul 2014 18:01:55 -0400 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:34662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X7AnH-0007jm-2Q for qemu-devel@nongnu.org; Tue, 15 Jul 2014 18:01:51 -0400 Received: by mail-wi0-f175.google.com with SMTP id ho1so5135214wib.2 for ; Tue, 15 Jul 2014 15:01:50 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53C5A4C9.80609@redhat.com> Date: Wed, 16 Jul 2014 00:01:45 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20140715050318.GD26186@grmbl.mre> <20140715210948.GA20036@amt.cnet> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrey Korolyov , Marcelo Tosatti Cc: Amit Shah , Fam Zheng , "qemu-devel@nongnu.org" Il 15/07/2014 23:25, Andrey Korolyov ha scritto: > On Wed, Jul 16, 2014 at 1:09 AM, Marcelo Tosatti wrote: >> On Tue, Jul 15, 2014 at 06:01:08PM +0400, Andrey Korolyov wrote: >>> On Tue, Jul 15, 2014 at 10:52 AM, Andrey Korolyov wrote: >>>> On Tue, Jul 15, 2014 at 9:03 AM, Amit Shah wrote: >>>>> On (Sun) 13 Jul 2014 [16:28:56], Andrey Korolyov wrote: >>>>>> Hello, >>>>>> >>>>>> the issue is not specific to the iothread code because generic >>>>>> virtio-blk also hangs up: >>>>> >>>>> Do you know which version works well? If you could bisect, that'll >>>>> help a lot. >>>>> >>>>> Thanks, >>>>> Amit >>>> >>>> Hi, >>>> >>>> 2.0 works definitely well. I`ll try to finish bisection today, though >>>> every step takes about 10 minutes to complete. >>> >>> Yay! It is even outside of virtio-blk. >>> >>> commit 9b1786829aefb83f37a8f3135e3ea91c56001b56 >>> Author: Marcelo Tosatti >>> Date: Tue Jun 3 13:34:48 2014 -0300 >>> >>> kvmclock: Ensure proper env->tsc value for kvmclock_current_nsec calculation >>> >>> Ensure proper env->tsc value for kvmclock_current_nsec calculation. >>> >>> Reported-by: Marcin GibuĊ‚a >>> Cc: qemu-stable@nongnu.org >>> Signed-off-by: Marcelo Tosatti >>> Signed-off-by: Paolo Bonzini >> >> Andrey, >> >> Can you please provide instructions on how to create reproducible >> environment? >> >> The following patch is equivalent to the original patch, for >> the purposes of fixing the kvmclock problem. >> >> Perhaps it becomes easier to spot the reason for the hang you are >> experiencing. >> >> >> diff --git a/hw/i386/kvm/clock.c b/hw/i386/kvm/clock.c >> index 272a88a..feb5fc5 100644 >> --- a/hw/i386/kvm/clock.c >> +++ b/hw/i386/kvm/clock.c >> @@ -17,7 +17,6 @@ >> #include "qemu/host-utils.h" >> #include "sysemu/sysemu.h" >> #include "sysemu/kvm.h" >> -#include "sysemu/cpus.h" >> #include "hw/sysbus.h" >> #include "hw/kvm/clock.h" >> >> @@ -66,7 +65,6 @@ static uint64_t kvmclock_current_nsec(KVMClockState *s) >> >> cpu_physical_memory_read(kvmclock_struct_pa, &time, sizeof(time)); >> >> - assert(time.tsc_timestamp <= migration_tsc); >> delta = migration_tsc - time.tsc_timestamp; >> if (time.tsc_shift < 0) { >> delta >>= -time.tsc_shift; >> @@ -125,8 +123,6 @@ static void kvmclock_vm_state_change(void *opaque, int running, >> if (s->clock_valid) { >> return; >> } >> - >> - cpu_synchronize_all_states(); >> ret = kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, &data); >> if (ret < 0) { >> fprintf(stderr, "KVM_GET_CLOCK failed: %s\n", strerror(ret)); >> diff --git a/migration.c b/migration.c >> index 8d675b3..34f2325 100644 >> --- a/migration.c >> +++ b/migration.c >> @@ -608,6 +608,7 @@ static void *migration_thread(void *opaque) >> qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER); >> old_vm_running = runstate_is_running(); >> >> + cpu_synchronize_all_states(); >> ret = vm_stop_force_state(RUN_STATE_FINISH_MIGRATE); >> if (ret >= 0) { >> qemu_file_set_rate_limit(s->file, INT64_MAX); It could also be useful to apply the above patch _and_ revert a096b3a6732f846ec57dc28b47ee9435aa0609bf, then try to reproduce. Paolo