> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx]
>
> > Below is test result:
> > a) With the patch
> > Before hotadd:
> > (XEN) TSC marked as reliable, warp = 0 (count=3)
> > (XEN) No domains have emulated TSC
> > (XEN) TSC marked as reliable, warp = 0 (count=4)
> > (XEN) No domains have emulated TSC
> > (XEN) TSC marked as reliable, warp = 0 (count=5)
> > (XEN) No domains have emulated TSC
> > (XEN) TSC marked as reliable, warp = 0 (count=6)
> > (XEN) No domains have emulated TSC
> >
> > After add
> > (XEN) TSC marked as reliable, warp = 1669912421214 (count=15)
> > (XEN) No domains have emulated TSC
> > (XEN) TSC marked as reliable, warp = 1669912421214 (count=16)
> > (XEN) No domains have emulated TSC
>
> If the warp is fixed, at least for HVM, this can be solved by adjusting
> the TSC_OFFSET with the additional warp to make guest see warp=0 for
> TSC invariant case. Anything missed?
Hi Eddie --
Two things:
1) The TSC_OFFSET doesn't work for PV domains.
2) For HVM, it is very difficult to choose a precise TSC_OFFSET so
that it passes a warp test. If it doesn't pass a warp test,
upstream kernels will stop using tsc as a clocksource resulting
in a big performance loss... and some applications that use TSC
and are not TSC resilient that may have been working fine
for weeks may suddenly break due to an event (adding a physical
CPU to Xen) that neither the app nor its (guest) OS is able
to detect.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home