From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [[RFC] KVM-S390: Provide guest TOD Clock Get/Set Controls Date: Wed, 08 Oct 2014 16:55:33 +0200 Message-ID: <54355065.5040903@suse.de> References: <1411136399-29936-1-git-send-email-jjherne@us.ibm.com> <541C7B47.9010707@de.ibm.com> <541C9429.3030303@suse.de> <541FE712.2050206@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: aik@ozlabs.ru, cornelia.huck@de.ibm.com, kvm@vger.kernel.org To: Jason Herne , Christian Borntraeger Return-path: Received: from cantor2.suse.de ([195.135.220.15]:50492 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752503AbaJHOzf (ORCPT ); Wed, 8 Oct 2014 10:55:35 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 08.10.14 16:09, Jason Herne wrote: > Christian Borntraeger wrote on 09/22/2014 > 05:08:34 AM: > ... >> Actually, I would expect something different (more or less something >> like standby/resume). >> >> In fact Jasons code that we have internally in testing is doing the >> simple approach >> 1. source reads guest time at migration end >> 2. target sets guest time from source >> >> So we have the guarantee that the time will never move backwards. It >> also works quite well for migration. As a bonus, we could really >> reuse the existing ioctl. >> >> I asked Jason to explore alternatives, though: I think it is somehow >> wrong, if you save a guest into an image file, open that one month >> later and the guest will always be 1 month behind unless it uses >> some kind of ntp. If everybody agrees that this is fine, I will >> queue up Jasons intial patch (simple get/set). >> The only question is then: shall we use an s390 specific ioctl (e.g. >> via VM attribute) or just use the existing KVM_SET_CLOCK. >> But maybe lets answer the first question before we decide on this. > > Ping. Does anyone feel strongly about this issue? I'm interested in > opinions so we can get s390 TOD clock migration working :). > > We need to decide which interface to use, s390 specific ioctl or > KVM_SET_CLOCK. I don't have any particular preference. If anything, I'm leaning towards KVM_SET_CLOCK. > Then we need to decide if we're going to snap a guest clock forward > on the resume of a "suspend to disk" type operation. The alternative > is to fix up the guest TOD value such that the guest notices no > change of time, which as Christian points out, seems wrong. Unless we > really want to show no time change and force the guest to use ntp to > figure out that he is behind. Just do it the same as x86 :). Alex