Re: kvm-clock again

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-04-05 15:07+0000, Avi Cohen:
> What do you think about this simple solution:
>  Currently  the KVM updates the system-time in the structure pvclock_vcpu_time_info  in the guest memory  with the MONOTONIC time 
> struct pvclock_vcpu_time_info {
>         u32   version;
>         u32   pad0;
>         u64   tsc_timestamp;
>         u64   system_time;
>         u32   tsc_to_system_mul;
>         s8    tsc_shift;
>         u8    flags;
>         u8    pad[2];
> } __attribute__((__packed__));
> 
> This is the default kvm-clcok.
> I think to add another clock source named - kvm-clock-realtime, and to update system_time with host's REAL_TIME clock.
> What is your opinion ?

Would you be ok with a wall_time entry in pvclock_vcpu_time_info that
would tell the host real time at system_time?
struct pvclock_wall_clock should say the host real time when system_time
was 0, so it's the same.  wallclock = CLOCK_REALTIME, most likely.

Creating a new clock would allow us to get rid of many other problems,
but your goal might be achievable with existing interfaces.

> I want to enter the KVM  code and try to make a REAL_TIME and accurate synchronization between the host and  guest  clocks .
> Currently I don’t see that KVM  updates the guest’s clock when I manually set the host’s clock. I don’t see any impact on the guest’s clock Also after booting the guest I see a  diff-time of ~1ms between the 2 clocks. 
> Questions:
> - What can you tell about the feasibility of this task ?

Doable.

> - 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
- changes in wallclock should trigger guest notifiers as if the change
  was done by the guest
- wallclock is updated only when the guest writes to the MSR, which
  would be wasteful for frequent reads and not possible in userspace

We'll have enough experience to decide on followup if no solution using
the existing framework is acceptable.