This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support for SVM

To: Wei Huang <wei.huang2@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxx>
Subject: RE: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support for SVM
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 27 May 2011 13:41:06 -0700 (PDT)
Delivery-date: Fri, 27 May 2011 19:53:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DDFD2B3.9070206@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DDFD2B3.9070206@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> From: Wei Huang [mailto:wei.huang2@xxxxxxx]
> Sent: Friday, May 27, 2011 10:35 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx; Keir Fraser
> Subject: [Xen-devel] [PATCH] SVM: enables TSC scaling ratio support for
> 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 <wei.huang2@xxxxxxx>

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

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)?


Xen-devel mailing list