Alok Kataria wrote:
quoted text
> Hi Gerd,
> 
> As Zach explained, we support a view that, tsc is constant.

Ok, so the guest doesn't have to worry about possible tsc changes when
using that interface.  Should go into the comment documenting the leaf.

quoted text
> Coming back to the migration problem, as you too acknowledge, migration
> to a host with a different frequency should be seen as a different
> problem. I would be interested in learning about any proposal that you
> may have thought about to handle this.

xen paravirtualized is explained below.

xen full virtualized: dunno.

kvm: provide something else for timekeeping to avoid the tsc trouble
altogether if possible.  hpet, pm_timer, paravirtualized clocksource.
Obviously can't work for all guests though.  paravirtual clocksource
works like the xen one.

cheers,
  Gerd

quoted text
>>> What special things does Xen do at migration, which would be affected by
>>> this interface ?
>> paravirtualized xen guests have a paravirtual clock.  That is a struct
>> containing three pieces of information: system time, tsc counter for the
>> last system time update, tsc frequency.  The guest gets the current time
>> by reading the system time and adding a delta calculated from current
>> tsc, tsc of last systime update and tsc frequency.  Handling tsc
>> frequency changes is obviously trivial here, just update the field on
>> the next systime update ;)
> 
> Oh nice, that is convenient. 
> 
> Thanks,
> Alok
> 
> 

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/