RE: kvm-clock again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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���)ߣ�

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux