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


[Xen-devel] tsc_mode == 1 and hvm guests

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] tsc_mode == 1 and hvm guests
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 6 May 2010 12:41:44 +0100
Delivery-date: Thu, 06 May 2010 04:40:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
Hi all,
going through the vtsc code in xen I realized that vtsc_offset and, more
importantly, vtsc_to_ns/ns_to_vtsc are never used for hvm guests.
That means that if tsc_mode == 1 the rdtsc values returned to pv guests
and the ones returns to hvm guests are fundamentally different because
in the first case they are scaled by the guest tsc frequency and in the
second case they are not.
The fact that noone at the moment is calling tsc_set_info with gtsc_khz
!= 0 doesn't help spotting this problem.

Is there a reason for this or is it just a bug?

Also there are two gtsc_khz AFAICT: d->arch.tsc_khz and
d->arch.hvm_domain.gtsc_khz, why hvm guests have their own separate
record of the guest tsc frequency, when they never actually change it?

BTW I noticed these problems because they prevent the pvclock algorithm
from working correctly in a PV on HVM linux guest.



Xen-devel mailing list