From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6GWP-0001ea-Jb for qemu-devel@nongnu.org; Mon, 14 Nov 2016 07:38:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6GWK-000500-OZ for qemu-devel@nongnu.org; Mon, 14 Nov 2016 07:38:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53260) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6GWK-0004yZ-J0 for qemu-devel@nongnu.org; Mon, 14 Nov 2016 07:37:56 -0500 Date: Fri, 11 Nov 2016 12:23:47 -0200 From: Marcelo Tosatti Message-ID: <20161111142344.GA7217@amt.cnet> References: <20161104094322.GA16930@amt.cnet> <20161104165933.GA3027@amt.cnet> <20161107154610.GG2054@work-vm> <20161107194058.GB28327@amt.cnet> <20161107200349.GC1155@work-vm> <20161108000609.GA3689@amt.cnet> <20161108102255.GC2042@work-vm> <4c34da7d-7027-5595-012a-61ab6937f8e3@redhat.com> <20161110114826.GA28418@amt.cnet> <7e62defb-dcbe-492d-3c05-056b13d6699a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e62defb-dcbe-492d-3c05-056b13d6699a@redhat.com> Subject: Re: [Qemu-devel] [QEMU PATCH v2] kvmclock: advance clock by time window between vm_stop and pre_save List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Dr. David Alan Gilbert" , kvm@vger.kernel.org, qemu-devel , Radim =?utf-8?B?S3LEjW3DocWZ?= , Juan Quintela , Eduardo Habkost On Thu, Nov 10, 2016 at 06:57:21PM +0100, Paolo Bonzini wrote: > > > On 10/11/2016 12:48, Marcelo Tosatti wrote: > > Destination has to run the following logic: > > > > If (source has KVM_CAP_ADVANCE_CLOCK) > > use KVM_GET_CLOCK value > > Else > > read pvclock from guest > > > > To support migration from older QEMU versions which do not have > > KVM_CAP_ADVANCE_CLOCK (or new QEMU versions running on old > > hosts without KVM_CAP_ADVANCE_CLOCK). > > > > I don't see any clean way to give that information, except changing > > the migration format to pass "host: kvm_cap_advance_clock=true/false" > > information. > > If you make it only affect new machine types, you could transmit a dummy > clock value such as -1 if the source does not have KVM_CLOCK_TSC_STABLE. > > Paolo Prefer a new subsection (which is fine since migration is broken anyway), because otherwise you have to deal with restoring s->clock from -1 to what was read at KVM_GET_CLOCK (in case migration fails).