From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: kvm-clock again Date: Thu, 7 Apr 2016 16:20:55 +0200 Message-ID: <20160407142055.GA13122@potion.brq.redhat.com> References: <20160405202524.GB29308@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "kvm@vger.kernel.org" To: Avi Cohen Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47868 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116AbcDGOU7 (ORCPT ); Thu, 7 Apr 2016 10:20:59 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-04-07 07:09+0000, Avi Cohen: >> From: Radim Kr=C4=8Dm=C3=A1=C5=99 [mailto:rkrcmar@redhat.com] >> > - Can you give me a reference/guides=C2=A0 for this task=E2=80=99s= =C2=A0design ? where to start ? >> potential problems ? pvclock ? when to update , when reentering the = VM ? etc.. >>=20 >> Start by using kvm_get_wallclock to pass the host CLOCK_REALTIME int= o the >> guest and turn wallclock into guest CLOCK_REALTIME. >>=20 >> A reasonable solution would be to create a thread that periodically = synchronizes >> CLOCK_REALTIME with wallclock. The wallclock thread would behave li= ke >> PTP/NTP, so it should be easy to do. >> (A notification from the host that the wallclock has changed would = be better, >> but needs new interface.) >>=20 >> I think that using wallclock directly as CLOCK_REALTIME would cause = more >> complications: >> - many guest interfaces expect that they can touch CLOCK_REALTIME, b= ut >> that shouldn't be allowed > Do you mean simultaneously guests write to MSR ?=20 I meant interface like clock_settime() -- we probably never denied writ= e access before, so some buggy userspace applications could misbehave. Even if we silently ignore the write, then people would definitely come complaining: "`date -s 0` doesn't work!". Wasted time all around. > Guests running on different physical CPU's can simultaneously write t= o the MSR and this should trigger kvm update of wall-clock - correct ? Yes, wall-clock is per-guest. (Note that simultaneous writes to this MSR from one guest are buggy, bu= t the guest doesn't have a reason to access it simultaneously, because t= he MSR is actually global.) > I understand that guest writing to MSR does not necessarily trigger = VM-exit - correct ? No, it always exits. The CPU doesn't know how to emulate that MSR. >> - changes in wallclock should trigger guest notifiers as if the chan= ge >> was done by the guest > I don=E2=80=99t understand what do u mean here.=20 Let's say the guest wants to do something at 12:00:00 and it's 11:59:00 now. The guest creates a timer with 60 second timeout. Then the host advances its CLOCK_REALTIME by 10 seconds. The timeout would expire at 12:00:10 after that, so the guest has to notice that CLOCK_REALTIME has changed and modify its timers. > if for example the host's clock was changed because of PTP time-set, = then after some time a guest is writing to MSR to get host real-time cl= ock , > I expect that the new wall clock update will include this time-set.=20 It will, but the guest must know that the time has changed, because of decisions that were made with the old time. (Any behavior can be excused when time is considered, but humans tend not to be that benevolent.) >> - wallclock is updated only when the guest writes to the MSR, which >> would be wasteful for frequent reads and not possible in userspace >>=20 > As you suggest - this will be performed by a new kernel thread which = should only write to the MSR and exit. i.e. it will not look into the w= all-clock structure. > Only when user application is requesting the current time (clock_gett= ime) - this call (clock_gettime or a another new call) will check the = content of the=20 > pvclock_wall_clock and calculate the current time. No, this is the problematic solution, just avoiding the MSR overhead. wall-clock should be used in the thread to set the time. Rough idea: while sleep(magic): do_settimeofday64(kvm_get_wallclock()) The polished solution should change the time like PTP/NTP does.