Gerd Hoffmann wrote:
> * Host: make kvm pv clock really compatible with xen pv clock.
> * Guest/xen: factor out some xen clock code into a separate
> source file (pvclock.[ch]), so kvm can reuse it.
> * Guest/kvm: make kvm clock compatible with xen clock by using
> the common code bits.
>
I guess saving on code duplication is good...
> +cycle_t pvclock_clocksource_read(struct kvm_vcpu_time_info *src)
> +{
> + struct pvclock_shadow_time *shadow = &get_cpu_var(shadow_time);
> + cycle_t ret;
> +
> + pvclock_get_time_values(shadow, src);
> + ret = shadow->system_timestamp + pvclock_get_nsec_offset(shadow);
>
You need to put this in a loop in case the system clock parameters
change between the pvclock_get_time_values() and pvclock_get_nsec_offset().
How does kvm deal with suspend/resume with respect to time? Is the
"system" timestamp guaranteed to remain monotonic? For Xen, I think
we'll need to maintain an offset between the initial system timestamp
and whatever it is after resuming.
J
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
