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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
