From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH 1/1] kvm-s390: Provide guest TOD Clock Get/Set Controls Date: Thu, 06 Nov 2014 09:46:37 +0100 Message-ID: <545B356D.7040808@de.ibm.com> References: <1414424654-21946-1-git-send-email-jjherne@linux.vnet.ibm.com> <1414424654-21946-2-git-send-email-jjherne@linux.vnet.ibm.com> <5459F6E0.8080400@suse.de> <545A17EF.4090004@de.ibm.com> <545A2209.9010603@redhat.com> <545A54FA.5040802@de.ibm.com> <545A604C.3010202@suse.de> <545A64DB.6000100@de.ibm.com> <545A7E67.5020507@redhat.com> <545B34B7.2070401@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Paolo Bonzini , Alexander Graf , "Jason J. Herne" , kvm@vger.kernel.org, cornelia.huck@de.ibm.com, aik@ozlabs.ru Return-path: Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:34254 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751896AbaKFIqn (ORCPT ); Thu, 6 Nov 2014 03:46:43 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Nov 2014 08:46:41 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id B24F417D8045 for ; Thu, 6 Nov 2014 08:46:46 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sA68keYD14156138 for ; Thu, 6 Nov 2014 08:46:40 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sA68kcFI014543 for ; Thu, 6 Nov 2014 01:46:39 -0700 In-Reply-To: <545B34B7.2070401@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 06.11.2014 09:43, schrieb Christian Borntraeger: > Am 05.11.2014 20:45, schrieb Paolo Bonzini: >> >> >> On 05/11/2014 18:56, Christian Borntraeger wrote: >>>>> >>>>> Whether you want to follow that approach or do it as VM attribute >>>>> straight away, I don't mind much :). >>> given that top programmable field and epoch are available as ONEREG, lets do the same for TOD. >> >> Is the epoch per-cpu? > > two answers :-) > > - the implementation is one epoch per control block, so someone could do that per CPU...but: > - guest TOD == host TOD + epochdiff. architecture mandates that there is only one TOD per system, so all guest TODs must be synced and so must be all epochdiffs > > Some background. We provided access to the epoch value about 2 years ago with other things as ONEREG. Asumming that all hosts are time synced, we could just migrate the epoch value. > Now: this is not the case all the time. Just migrating the epoch could result in time jumping forth and back. > > This thing is now: QEMU cannot calculate a correction reliably, because it cannot rely on the value of the TOD (by using stck) since the kernel might do tricks with the host TOD value as soon as we enable time synching between z boxes. > (Thats why normal userspace should not use stck either, it should use gettimeofday because the kernel might have offsets etc due to NTP or time synching between boxes). So we finally cam up with just migrating the guest visible TOD, which seems to work fine. > > As a recap we have now: > #define KVM_REG_S390_TODPR (KVM_REG_S390 | KVM_REG_SIZE_U32 | 0x1) > #define KVM_REG_S390_EPOCHDIFF (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x2) > > and we would > add > #define KVM_REG_S390_TOD (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x3) > #define KVM_REG_S390_TOD_INDEX (KVM_REG_S390 | KVM_REG_SIZE_U8 | 0x4) obviously not 0x3 and 0x4 but something higher..