Xen devel - Dec 2008 - Guest time and TSCs since changeset 17716

Changeset 17716 provides monotonically increasing guest time for HVM 
domains, by using the per-domain pl_time structure. hvm_get_guest_time 
and hvm_set_guest_time were changed to use this. Previously, the guest 
time was stored directly in the TSC offset fields of the vmx/smv control 
structures.

Since pt_freeze_time and pt_thaw_time use hvm_get/set_guest_time, they 
now no longer freeze TSC time for a guest. So, for timer_mode 0, TSC 
time is no longer frozen when a VCPU is not running. Unless you''re
using
opt_softtsc, in which TSC exactly tracks the per-domain values.

I have no love for timer_mode 0 (it has serious issues on SMP), but was 
this change intentional? Or am I perhaps missing something?

- Frank


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 29/12/2008 17:23, "Frank Van Der Linden"
<Frank.Vanderlinden@Sun.COM>
wrote:
> Changeset 17716 provides monotonically increasing guest time for HVM
> domains, by using the per-domain pl_time structure. hvm_get_guest_time
> and hvm_set_guest_time were changed to use this. Previously, the guest
> time was stored directly in the TSC offset fields of the vmx/smv control
> structures.
> 
> Since pt_freeze_time and pt_thaw_time use hvm_get/set_guest_time, they
> now no longer freeze TSC time for a guest. So, for timer_mode 0, TSC
> time is no longer frozen when a VCPU is not running. Unless you''re
using
> opt_softtsc, in which TSC exactly tracks the per-domain values.
> 
> I have no love for timer_mode 0 (it has serious issues on SMP), but was
> this change intentional? Or am I perhaps missing something?
It sounds unintentional, but as you say no one really uses timer_mode 0 so I
suppose it''s gone unnoticed so far.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel