[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please)


  • To: <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Fri, 4 Jul 2008 08:56:58 +0800
  • Cc:
  • Delivery-date: Thu, 03 Jul 2008 17:57:29 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcjboIivPTuddHlLSIGPaPhte5VM5wASModQADA1FBAAMHiVIA==
  • Thread-topic: [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please)

>From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx] 
>Sent: 2008年7月3日 9:21
>>
>> Can't be the tsc kept monotonic to guest, with some tweak on
>> tsc offset? Also Xen is always trying to sync tsc among cores.
>> As long as you don't run on a box with multiple bus crystals,
>> or a box without constant tsc upon freq change, the tsc drift
>> among cores should be negligible considering the overhead of
>> migration. Then for cases out of 'as long as', we should mark
>> TSC as unstable, still as an option.
>
>No Xen doesn't actally sync the tsc's, just maintains its own
>software offset variables.  I suppose it could periodically check
>to make sure the tsc skew is within some reasonable value,
>but after the guest boots, it is probably too late.

You are right. Xen only sync TSCs at boot time and then calibrate
TSC pace independently on each cpu. If some factors drag TSC
in the middle, then we may observe larger drift. But now I'm not
sure whether periodically sync among cpus is light enough, if taking
a similar convergence algothrim as boot time. But still, if only TSC
drift exists (caused by occasional events instead of a constantly
increasing drift from freq difference), this monotonic can be easily
exposed to the guest, like derived from xen system time to adjust
TSC offset at migration...

>
>> >Another alternative would be to trap all rdtsc's and emulate
>> >them but this probably will not be easy and may have
>> >significant performance implications.  But perhaps it should
>> >be an option?
>>
>> Agree.
>
>Is this something that you (or Intel in general) could look at?
>I would be happy to participate but I don't think I understand
>VT well enough.  Once the trap occurs, I suppose Xen system time
>could be used as the virtual TSC, possibly scaled up.
>

There should be tiny related to VT, as only turning on some bit to
allow RDTSC trapping and then the rest stuff should be common
how to handle it. We'll take a look, but can't commit the time due
to other scheduled bandwidth. But if you'd like to jump in early
we definitely can help with VT side.

Thanks,
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.