From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: kvm-clock again Date: Thu, 14 Apr 2016 20:23:22 +0200 Message-ID: <20160414182321.GA18374@potion.brq.redhat.com> References: <20160405202524.GB29308@potion.brq.redhat.com> <20160407142055.GA13122@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kvm@vger.kernel.org" To: Avi Cohen Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56693 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755030AbcDNSXZ (ORCPT ); Thu, 14 Apr 2016 14:23:25 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-04-13 12:46+0000, Avi Cohen: > Hi Radim, > 1. What do you think is the reason for the real-time clock difference (about 800ms) between guest and host , measured just a short time after boot ? > The host set the guest's wall-clock with its real-time clock @ boot , I see in the code that the guest tries to fetch this time in a loop - till it verifies that the version field (in the wall-clock structure) was changed - which means that the host wrote it's clock to the wall-clock page. > What can be the reason for this big delta/error ? The guest then overwrites wall-clock time with time from emulated RTC, which could explain some delay and then the measurement will add more, but 800 ms is ridiculously large ... most likely a bug somewhere, but it's hard to guess without knowing your whole setup. > 2. when the host updates the system/monotonic -clock page (pvclock_system_time), whenever it re-enters the guest. It updates also the guest's TSC(**) at this current time. KVM doesn't update pvclock_system_time on every entry when you have master_clock (which you should). > I understand that this TSC is per guest/VCPU - correct ? tsc_timestamp is per VCPU, it is TSC value at the same time when system_time was taken. If you have master_clock, then tsc_timestamp has to be identical on all VCPUs. > how accurate is this TSC ? Perfectly, host and guest use the same TSC, the guest just have some offset and scaling that it doesn't know about. > is it virtualized ? I'm not sure what you're asking for. > When guest reads its TSC by RDTSC - this does not trigger VM-exit . how this TSC (read by guest) is related to the prev. TSC(**) which is updated by host ? RDTSC in the guest does not exit, CPU just reads the TSC value, applies offset and scaling, and gives it to the guest. > how this TSC (read by guest) is related to the prev. TSC(**) which is updated by host ? If the guest could RDTSC at the time when the host updated TSC(**), then the guest would have read that value. > 3. suppose the host is running a PTP and I'm going to implement a periodic kernel thread to query the host's real-time clock every 1 second. Why do you this that implementing another 'PTP like' clock/frequency adjustment in the guest is required ? You need to synchronize the time and PTP and NTP deal with time synchronization, so they are likely using all necessary interfaces to set the time -- you'll just plug wall-clock, because wall-clock is a simple Time Protocol.