Re: kvm-clock again

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

2016-04-13 12:46+0000, Avi Cohen:
> Hi Radim,
> 1. What do you think is the reason for the real-time clock difference (about 800ms) between guest and host , measured just a short time after boot ?
> The host set the guest's wall-clock with its real-time clock @ boot , I  see in the code that the guest tries to fetch this time in a loop  - till it verifies that the version field (in the wall-clock structure) was changed - which means that the host wrote it's clock to the wall-clock page. 
> What can be the reason for this big delta/error ?

The guest then overwrites wall-clock time with time from emulated RTC,
which could explain some delay and then the measurement will add more,
but 800 ms is ridiculously large ... most likely a bug somewhere, but
it's hard to guess without knowing your whole setup.

> 2. when the host updates the system/monotonic -clock page (pvclock_system_time), whenever it re-enters the guest. It updates also the guest's TSC(**)  at this current time.

KVM doesn't update pvclock_system_time on every entry when you have
master_clock (which you should).

> I understand that this TSC is per guest/VCPU - correct ?

tsc_timestamp is per VCPU, it is TSC value at the same time when
system_time was taken.  If you have master_clock, then tsc_timestamp has
to be identical on all VCPUs.

> how accurate is this TSC ?

Perfectly, host and guest use the same TSC, the guest just have some
offset and scaling that it doesn't know about.

> is it virtualized ? 

I'm not sure what you're asking for.

> When guest reads its TSC by RDTSC -  this does not trigger VM-exit .  how this TSC (read by guest) is related to the prev. TSC(**) which is updated by host  ? 

RDTSC in the guest does not exit, CPU just reads the TSC value, applies
offset and scaling, and gives it to the guest.

> how this TSC (read by guest) is related to the prev. TSC(**) which is updated by host  ? 

If the guest could RDTSC at the time when the host updated TSC(**), then
the guest would have read that value.

> 3. suppose the host is running a PTP and I'm going to implement a periodic kernel thread to query the host's real-time clock every 1 second. Why do you this that implementing another 'PTP like' clock/frequency  adjustment in the guest is required ?

You need to synchronize the time and PTP and NTP deal with time
synchronization, so they are likely using all necessary interfaces to
set the time -- you'll just plug wall-clock, because wall-clock is a
simple Time Protocol.