SVM: enables TSC scaling ratio support for SVM

PATCH In review Wei Huang 2 participants 4 messages May 27, 2011 – May 28, 2011

Share & tools

Wei Huang

author

2011-05-27 16:34 UTC #0 lore raw

PATCH 1/1 SVM: enables TSC scaling ratio support for SVM

Future AMD CPUs support TSC scaling. It allows guests to have a different TSC frequency from host system using this formula: guest_tsc = host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR contains a fixed-point number in 8.32 format (8 bits for integer part and 32bits for fractional part). For instance 0x00000003_80000000 means tsc_ratio=3.5.

This patch enables TSC scaling ratio for SVM. With it, guest VMs don't need take #VMEXIT to calculate a translated TSC value when it is running under TSC emulation mode. This can SUBSTANTIALLY reduce the rdtsc overhead.

Signed-off-by Wei Huang <[email protected]>

 arch/x86/hvm/svm/svm.c        |   32 +++++++++++++++++++++++++++++++-
 arch/x86/hvm/svm/vmcb.c       |    4 +++-
 include/asm-x86/hvm/svm/svm.h |    8 ++++++++
 include/asm-x86/msr-index.h   |    3 +++
 4 files changed, 45 insertions(+), 2 deletions(-)

# HG changeset patch
# User Wei Huang <[email protected]>
# Date 1306514223 18000
# Node ID 83e24e4232bf0f886543e56c7dac3ae958e6d3eb # Parent 14eb8e1fcd828e4610df05e5d781e5f9693fd65c HVM/SVM: enable tsc scaling ratio for SVM

This patch enables TSC scaling ratio for SVM. With it, guest VMs don't need take #VMEXIT to calculate a translated TSC value when it is running under TSC emulation mode. This can substancially reduce the rdtsc overhead.

Signed-off-by Wei Huang <[email protected]>

xen/arch/x86/hvm/svm/svm.c +31 -1

diff -r 14eb8e1fcd82 -r 83e24e4232bf xen/arch/x86/hvm/svm/svm.c
@@ -640,8 +640,23 @@
     struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
     struct vmcb_struct *n1vmcb, *n2vmcb;
     uint64_t n2_tsc_offset = 0;
+    struct domain *d = v->domain;
 
-    if ( !nestedhvm_enabled(v->domain) ) {
+    if ( !nestedhvm_enabled(d) ) {
+        /* Re-adjust the offset value when TSC_RATIO is available */
+        if ( cpu_has_tsc_ratio && d->arch.vtsc )
+        {
+            uint64_t host_tsc, guest_tsc;
+
+            rdtscll(host_tsc);
+            guest_tsc = hvm_get_guest_tsc(v);
+            
+            /* calculate hi,lo parts in 64bits to prevent overflow */
+            offset = (((host_tsc >> 32) * d->arch.tsc_khz / cpu_khz) << 32) +
+                     (host_tsc & 0xffffffffULL) * d->arch.tsc_khz / cpu_khz;
+            offset = guest_tsc - offset;
+        }
+
         vmcb_set_tsc_offset(vmcb, offset);
         return;
     }

@@ -749,6 +764,19 @@
     return 0;
 }
 
+static inline void svm_tsc_ratio_save(struct vcpu *v)
+{
+    /* Other vcpus might not have vtsc enabled. So disable TSC_RATIO here. */
+    if ( cpu_has_tsc_ratio && v->domain->arch.vtsc )
+        wrmsrl(MSR_AMD64_TSC_RATIO, DEFAULT_TSC_RATIO);
+}
+
+static inline void svm_tsc_ratio_load(struct vcpu *v)
+{
+    if ( cpu_has_tsc_ratio && v->domain->arch.vtsc ) 
+        wrmsrl(MSR_AMD64_TSC_RATIO, vcpu_tsc_ratio(v));
+}
+
 static void svm_ctxt_switch_from(struct vcpu *v)
 {
     int cpu = smp_processor_id();

@@ -758,6 +786,7 @@
     svm_save_dr(v);
     vpmu_save(v);
     svm_lwp_save(v);
+    svm_tsc_ratio_save(v);
 
     svm_sync_vmcb(v);
     svm_vmload(per_cpu(root_vmcb, cpu));

@@ -802,6 +831,7 @@
     vmcb->cleanbits.bytes = 0;
     vpmu_load(v);
     svm_lwp_load(v);
+    svm_tsc_ratio_load(v);
 
     if ( cpu_has_rdtscp )
         wrmsrl(MSR_TSC_AUX, hvm_msr_tsc_aux(v));

xen/arch/x86/hvm/svm/vmcb.c +3 -1

diff -r 14eb8e1fcd82 -r 83e24e4232bf xen/arch/x86/hvm/svm/vmcb.c
@@ -128,7 +128,9 @@
 
     /* TSC. */
     vmcb->_tsc_offset = 0;
-    if ( v->domain->arch.vtsc )
+
+    /* Don't need to intercept RDTSC if CPU supports TSC rate scaling */
+    if ( v->domain->arch.vtsc && !cpu_has_tsc_ratio )
     {
         vmcb->_general1_intercepts |= GENERAL1_INTERCEPT_RDTSC;
         vmcb->_general2_intercepts |= GENERAL2_INTERCEPT_RDTSCP;

xen/include/asm-x86/hvm/svm/svm.h +8 -0

diff -r 14eb8e1fcd82 -r 83e24e4232bf xen/include/asm-x86/hvm/svm/svm.h
@@ -87,7 +87,15 @@
 #define cpu_has_svm_cleanbits cpu_has_svm_feature(SVM_FEATURE_VMCBCLEAN)
 #define cpu_has_svm_decode    cpu_has_svm_feature(SVM_FEATURE_DECODEASSISTS)
 #define cpu_has_pause_filter  cpu_has_svm_feature(SVM_FEATURE_PAUSEFILTER)
+#define cpu_has_tsc_ratio     cpu_has_svm_feature(SVM_FEATURE_TSCRATEMSR)
 
 #define SVM_PAUSEFILTER_INIT    3000
 
+/* TSC rate */
+#define DEFAULT_TSC_RATIO       0x0000000100000000ULL
+#define TSC_RATIO_RSVD_BITS     0xffffff0000000000ULL
+#define TSC_RATIO(g_khz, h_khz) ( (((u64)(g_khz)<<32)/(u64)(h_khz)) & \
+                                  ~TSC_RATIO_RSVD_BITS )
+#define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
+
 #endif /* __ASM_X86_HVM_SVM_H__ */

xen/include/asm-x86/msr-index.h +3 -0

diff -r 14eb8e1fcd82 -r 83e24e4232bf xen/include/asm-x86/msr-index.h
@@ -266,6 +266,9 @@
 #define MSR_AMD_PATCHLEVEL		0x0000008b
 #define MSR_AMD_PATCHLOADER		0xc0010020
 
+/* AMD TSC RATE MSR */
+#define MSR_AMD64_TSC_RATIO		0xc0000104
+
 /* AMD Lightweight Profiling MSRs */
 #define MSR_AMD64_LWP_CFG		0xc0000105
 #define MSR_AMD64_LWP_CBADDR		0xc0000106

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Dan Magenheimer

2011-05-27 20:41 UTC #1 lore raw

Quoted 14 lines

From: Wei Huang [mailto:[email protected]]
Sent: Friday, May 27, 2011 10:35 AM
To: [email protected]; Keir Fraser
Subject: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support for SVM
Future AMD CPUs support TSC scaling. It allows guests to have a different TSC frequency from host system using this formula: guest_tsc =
host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR contains a fixed-point number in 8.32 format (8 bits for integer part and 32bits for fractional part). For instance 0x00000003_80000000 means tsc_ratio=3.5.

Quoted 7 lines

This patch enables TSC scaling ratio for SVM. With it, guest VMs don't need take #VMEXIT to calculate a translated TSC value when it is running
under TSC emulation mode. This can SUBSTANTIALLY reduce the rdtsc overhead.
Signed-off-by Wei Huang <[email protected]>

Has this patch been tested across save/restore and migration, especially between machines with and without the feature and especially across many migrations where each physical machine has a different tsc_ratio?

ISTR that this feature does not really do a generic adjustment so may mis-scale time that has been accrued on one or more previous physical machines. In other words, I think the problem is that it does

(host_tsc * tsc_ratio) + offset

and not

((host_tsc + offset1) * tsc_ratio) + offset2

This can be fixed if you trust cpu_khz to be precise on all machines, but I don't think it is sufficiently precise to guarantee that time never goes backwards in a guest (though that may be fixable too). If time DOES go backwards and the guest detects it, it may switch to a much slower timer mechanism which could be worse than trapping rdtsc.

All of this is from vague recollection... if it is all fully tested across all cases (and sufficient testing proves that time never goes backwards), consider this just noting a concern.

Also, is this feature visible from an HVM guest kernel? Is it visible from a PV guest cpuid (e.g. OS or app)?

Thanks,
Dan

Wei Huang

author

2011-05-27 21:59 UTC #2 lore raw

Hi Dan,

I tested it by migrating between systems with TSC and without TSC, mainly using a Linux guest VM.

I might have missed your point. But what is offset1 in your formula? My understanding is that hvm_get_guest_tsc() returns a TSC value guests are supposed to use. So when guest_tsc is set, we can re-calculate offset=hvm_get_guest_tsc() - host_tsc * ratio. This is how current Xen is implemented. Also, as long as host_tsc doesn't go backwards (i.e. TSC_RELIABLE), host_tsc * ratio+offset should be reliable. Are you concerned that cpu_khz might be (slightly) different on different cores?

This feature is only available under SVM mode. HVM guests won't be able to see it in CPUID. PV guests shouldn't be able to change the value of this MSR.

Thanks,
-Wei

Quoted 56 lines · Dan Magenheimer

Quoted 14 lines
From: Wei Huang [mailto:[email protected]]
Sent: Friday, May 27, 2011 10:35 AM
To: [email protected]; Keir Fraser
Subject: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support for SVM
Future AMD CPUs support TSC scaling. It allows guests to have a different TSC frequency from host system using this formula: guest_tsc =
host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR contains a fixed-point number in 8.32 format (8 bits for integer part and 32bits for fractional part). For instance 0x00000003_80000000 means tsc_ratio=3.5.
Quoted 7 lines
This patch enables TSC scaling ratio for SVM. With it, guest VMs don't need take #VMEXIT to calculate a translated TSC value when it is running
under TSC emulation mode. This can SUBSTANTIALLY reduce the rdtsc overhead.
Signed-off-by Wei Huang<[email protected]>
Has this patch been tested across save/restore and migration, especially between machines with and without the feature and especially across many migrations where each physical machine has a different tsc_ratio?
ISTR that this feature does not really do a generic adjustment so may mis-scale time that has been accrued on one or more previous physical machines. In other words, I think the problem is that it does
(host_tsc * tsc_ratio) + offset
and not
((host_tsc + offset1) * tsc_ratio) + offset2
This can be fixed if you trust cpu_khz to be precise on all machines, but I don't think it is sufficiently precise to guarantee that time never goes backwards in a guest (though that may be fixable too). If time DOES go backwards and the guest detects it, it may switch to a much slower timer mechanism which could be worse than trapping rdtsc.
All of this is from vague recollection... if it is all fully tested across all cases (and sufficient testing proves that time never goes backwards), consider this just noting a concern.
Also, is this feature visible from an HVM guest kernel? Is it visible from a PV guest cpuid (e.g. OS or app)?
Thanks,
Dan

Dan Magenheimer

2011-05-28 17:39 UTC #3 lore raw

Quoted 12 lines

From: Wei Huang [mailto:[email protected]]
Sent: Friday, May 27, 2011 3:59 PM
To: Dan Magenheimer
Cc: [email protected]; Keir Fraser
Subject: Re: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support for SVM
Hi Dan,
I tested it by migrating between systems with TSC and without TSC, mainly using a Linux guest VM.

Quoted 9 lines

I might have missed your point. But what is offset1 in your formula? My understanding is that hvm_get_guest_tsc() returns a TSC value guests are
supposed to use. So when guest_tsc is set, we can re-calculate offset=hvm_get_guest_tsc() - host_tsc * ratio. This is how current Xen is implemented. Also, as long as host_tsc doesn't go backwards (i.e. TSC_RELIABLE), host_tsc * ratio+offset should be reliable. Are you concerned that cpu_khz might be (slightly) different on different cores?

offset1 is the last "virtualized" TSC value on the previous physical machine. offset2 is the value of TSC when the guest starts. (Does "virtualized" TSC always start at 0 on an HVM guest?) But my formula is just an attempt to restate the concern and I don't remember it exactly.

cpu_khz is missing 10 bits of precision (because it is khz, not hz) and multiplying by cpu_khz propagates and magnifies that loss of precision.

I *think* it may be OK as long as your "offset" is always greater than or equal to the last "virtualized" TSC value read by the guest... at least TSC will never be observed going backwards in the guest.

But I still have concern about the loss of precision after multiple migrations. (It may be possible to prove mathematically that it is OK... I'm just not a mathematician.)

Quoted 3 lines

This feature is only available under SVM mode. HVM guests won't be able to see it in CPUID. PV guests shouldn't be able to change the value of this MSR.

OK, thanks for the clarification.

Thanks,
Dan

Quoted 64 lines · Dan Magenheimer

Quoted 4 lines
Quoted 4 lines
From: Wei Huang [mailto:[email protected]]
Sent: Friday, May 27, 2011 10:35 AM
To: [email protected]; Keir Fraser
Subject: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support
for
Quoted 4 lines
Quoted 4 lines
SVM
Future AMD CPUs support TSC scaling. It allows guests to have a different TSC frequency from host system using this formula:
guest_tsc
Quoted 3 lines
Quoted 3 lines
=
host_tsc * tsc_ratio + vmcb_offset. The tsc_ratio is a 64bit MSR contains a fixed-point number in 8.32 format (8 bits for integer
part
Quoted 1 line
Quoted 1 line
and 32bits for fractional part). For instance 0x00000003_80000000
means
Quoted 3 lines
Quoted 3 lines
tsc_ratio=3.5.
This patch enables TSC scaling ratio for SVM. With it, guest VMs
don't
Quoted 41 lines
Quoted 6 lines
need take #VMEXIT to calculate a translated TSC value when it is running
under TSC emulation mode. This can SUBSTANTIALLY reduce the rdtsc overhead.
Signed-off-by Wei Huang<[email protected]>
Has this patch been tested across save/restore and migration, especially between machines with and without the feature and especially across many migrations where each physical machine has a different tsc_ratio?
ISTR that this feature does not really do a generic adjustment so may mis-scale time that has been accrued on one or more previous physical machines. In other words, I think the problem is that it does
(host_tsc * tsc_ratio) + offset
and not
((host_tsc + offset1) * tsc_ratio) + offset2
This can be fixed if you trust cpu_khz to be precise on all machines, but I don't think it is sufficiently precise to guarantee that time never goes backwards in a guest (though that may be fixable too). If time DOES go backwards and the guest detects it, it may switch to a much slower timer mechanism which could be worse than trapping rdtsc.
All of this is from vague recollection... if it is all fully tested across all cases (and sufficient testing proves that time never goes backwards), consider this just noting a concern.
Also, is this feature visible from an HVM guest kernel? Is it visible from a PV guest cpuid (e.g. OS or app)?
Thanks,
Dan