Re: [Xen-devel] [PATCH v2 14/14] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Zhang, Haozhong
> Sent: Monday, December 07, 2015 4:59 AM
g and tscmode.txt
> 
> Signed-off-by: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
> ---
>  docs/man/xl.cfg.pod.5 | 15 ++++++++++++++-
>  docs/misc/tscmode.txt | 14 ++++++++++++++
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 2aca8dd..7e19a9b 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -1313,9 +1313,18 @@ deprecated. Options are:
> 
>  =item B<"default">
> 
> -Guest rdtsc/p executed natively when monotonicity can be guaranteed
> +Guest rdtsc/p is executed natively when monotonicity can be guaranteed
>  and emulated otherwise (with frequency scaled if necessary).
> 
> +If a HVM container in B<default> TSC mode is not migrated from other hosts

"migrated from" -> "migrated to"?

> +and the host TSC monotonicity can be guaranteed, the guest and host TSC
> +frequencies will be the same.
> +
> +If a HVM container in B<default> TSC mode is migrated to a host that can
> +guarantee the TSC monotonicity and supports Intel VMX TSC scaling/AMD SVM

and -> or? Do we think TSC scaling a must to ensure TSC monotonicity? It comes
to the rescue only when host can't ensure monotonicity...

> +TSC ratio, guest rdtsc/p will still execute natively after migration and the
> +guest TSC frequencies before and after migration will be the same.

will be the same before and after migration.

> +
>  =item B<"always_emulate">
> 
>  Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
> @@ -1337,6 +1346,10 @@ determine when a restore/migration has occurred and
> assumes guest
>  obtains/uses pvclock-like mechanism to adjust for monotonicity and
>  frequency changes.
> 
> +If a HVM container in B<native_paravirt> TSC mode can execute both guest
> +rdtsc and guest rdtscp natively, then the guest TSC frequency will be
> +determined in the similar way to that of B<default> TSC mode.
> +
>  =back
> 
>  Please see F<docs/misc/tscmode.txt> for more information on this option.
> diff --git a/docs/misc/tscmode.txt b/docs/misc/tscmode.txt
> index e8c84e8..f3b70be 100644
> --- a/docs/misc/tscmode.txt
> +++ b/docs/misc/tscmode.txt
> @@ -297,3 +297,17 @@ and also much faster than nearly all OS-provided time
> mechanisms.
>  While pvrtscp is too complex for most apps, certain enterprise
>  TSC-sensitive high-TSC-frequency apps may find it useful to
>  obtain a significant performance gain.
> +
> +Hardware TSC Scaling
> +
> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read
> +by guest rdtsc/p increasing in the different frequency than the host

"in the different" -> "in a different"

> +TSC frequency.
> +
> +For a HVM container is in default TSC mode (tsc_mode=0) or PVRDTSCP

For a HVM container *which* is

> +mode (tsc_mode=3) and can execute both guest rdtsc and rdtscp
> +natively, if it is not migrated from other hosts, the guest and host
> +TSC frequencies will be the same. 

"the guest and host TSC frequencies remain the same if the guest is
not migrated to other host."

and the condition is that the host supports constant TSC feature.

> If it is migrated to a host
> +supporting Intel VMX TSC scaling/AMD SVM TSC ratio and can still
> +execute guest rdtsc and rdtscp natively, the guest TSC frequencies
> +before and after migration will be the same.
> --
> 2.6.3


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel