* [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal
@ 2017-03-17 18:15 Boris Ostrovsky
2017-03-20 8:03 ` Jan Beulich
2017-03-28 13:40 ` Olaf Hering
0 siblings, 2 replies; 3+ messages in thread
From: Boris Ostrovsky @ 2017-03-17 18:15 UTC (permalink / raw)
To: xen-devel; +Cc: andrew.cooper3, Boris Ostrovsky, jbeulich
Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and
host frequencies are the same") left out optimization for PV guests
when host and guest run at the same frequency.
For such a case we should be able not to use virtual TSC regardless
of whether we are runing before or after a migration (i.e. regardless
of incarnation value).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Suggested-by: Jan Beulich <JBeulich@suse.com>
---
Changes in v3:
* Replace ASSERT with a comment
xen/arch/x86/time.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b4988bf..69278c3 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -2024,17 +2024,16 @@ void tsc_set_info(struct domain *d,
d->arch.vtsc_offset = get_s_time() - elapsed_nsec;
d->arch.tsc_khz = gtsc_khz ?: cpu_khz;
set_time_scale(&d->arch.vtsc_to_ns, d->arch.tsc_khz * 1000);
+
/*
- * In default mode use native TSC if the host has safe TSC and:
- * HVM/PVH: host and guest frequencies are the same (either
- * "naturally" or via TSC scaling)
- * PV: guest has not migrated yet (and thus arch.tsc_khz == cpu_khz)
+ * When a guest is created gtsc_khz is passed in as zero,
+ * making d->arch.tsc_khz == cpu_khz. Thus no need to test
+ * 'incarnation == 0'.
*/
if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
- (is_hvm_domain(d) ?
- (d->arch.tsc_khz == cpu_khz ||
- hvm_get_tsc_scaling_ratio(d->arch.tsc_khz)) :
- incarnation == 0) )
+ (d->arch.tsc_khz == cpu_khz ||
+ (is_hvm_domain(d) &&
+ hvm_get_tsc_scaling_ratio(d->arch.tsc_khz))) )
{
case TSC_MODE_NEVER_EMULATE:
d->arch.vtsc = 0;
--
1.8.3.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal
2017-03-17 18:15 [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal Boris Ostrovsky
@ 2017-03-20 8:03 ` Jan Beulich
2017-03-28 13:40 ` Olaf Hering
1 sibling, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2017-03-20 8:03 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: andrew.cooper3, xen-devel
>>> On 17.03.17 at 19:15, <boris.ostrovsky@oracle.com> wrote:
> Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and
> host frequencies are the same") left out optimization for PV guests
> when host and guest run at the same frequency.
>
> For such a case we should be able not to use virtual TSC regardless
> of whether we are runing before or after a migration (i.e. regardless
> of incarnation value).
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Suggested-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal
2017-03-17 18:15 [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal Boris Ostrovsky
2017-03-20 8:03 ` Jan Beulich
@ 2017-03-28 13:40 ` Olaf Hering
1 sibling, 0 replies; 3+ messages in thread
From: Olaf Hering @ 2017-03-28 13:40 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: andrew.cooper3, jbeulich, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1308 bytes --]
Am Fri, 17 Mar 2017 14:15:26 -0400
schrieb Boris Ostrovsky <boris.ostrovsky@oracle.com>:
> Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and
> host frequencies are the same") left out optimization for PV guests
> when host and guest run at the same frequency.
>
> For such a case we should be able not to use virtual TSC regardless
> of whether we are runing before or after a migration (i.e. regardless
> of incarnation value).
I think this part of tscmode.txt may needs an update now.
Doesn't the "always emulated for PV" meant the part which was changed?
...
The default mode (tsc_mode==0) checks TSC-safeness of the underlying
hardware on which the virtual machine is launched. If it is
TSC-safe, rdtsc will execute at hardware speed; if it is not, rdtsc
will be emulated. Once a virtual machine is save/restored or migrated,
however, there are two possibilities: For a paravirtualized (PV) domain,
TSC will always be emulated. For a fully-virtualized (HVM) domain,
TSC remains native IF the source physical machine and target physical machine
have the same TSC frequency; else TSC is emulated. Note that, though
emulated, the "apparent" TSC frequency will be the TSC frequency
of the initial physical machine, even after migration.
...
Olaf
[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-28 13:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-17 18:15 [PATCH v3] x86/time: Don't use virtual TSC if host and guest frequencies are equal Boris Ostrovsky
2017-03-20 8:03 ` Jan Beulich
2017-03-28 13:40 ` Olaf Hering
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.