Thanks Radim I agree with you that the 'PTP like' clock/frequency adjustment will be very nice here Regards Avi > -----Original Message----- > From: Radim Krčmář [mailto:rkrcmar@xxxxxxxxxx] > Sent: Thursday, 07 April, 2016 5:21 PM > To: Avi Cohen > Cc: kvm@xxxxxxxxxxxxxxx > Subject: Re: kvm-clock again > > 2016-04-07 07:09+0000, Avi Cohen: > >> From: Radim Krčmář [mailto:rkrcmar@xxxxxxxxxx] > >> > - Can you give me a reference/guides for this task’s design ? where to start > ? > >> potential problems ? pvclock ? when to update , when reentering the VM ? > etc.. > >> > >> Start by using kvm_get_wallclock to pass the host CLOCK_REALTIME into > >> the guest and turn wallclock into guest CLOCK_REALTIME. > >> > >> A reasonable solution would be to create a thread that periodically > >> synchronizes CLOCK_REALTIME with wallclock. The wallclock thread > >> would behave like 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.) > >> > >> I think that using wallclock directly as CLOCK_REALTIME would cause > >> more > >> complications: > >> - many guest interfaces expect that they can touch CLOCK_REALTIME, but > >> that shouldn't be allowed > > Do you mean simultaneously guests write to MSR ? > > I meant interface like clock_settime() -- we probably never denied write 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 to 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, but the > guest doesn't have a reason to access it simultaneously, because the 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 change > >> was done by the guest > > I don’t understand what do u mean here. > > 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 clock , I > expect that the new wall clock update will include this time-set. > > 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 > >> > > 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 wall-clock structure. > > Only when user application is requesting the current time > > (clock_gettime) - this call (clock_gettime or a another new call) will check the > content of the 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. ��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
