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] softtsc for PV guests

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] softtsc for PV guests
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 21 Aug 2009 16:59:58 -0700
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 23 Aug 2009 01:58:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <dd256b18-7a63-4a4d-93fb-7c6208d2aeab@default>
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: <dd256b18-7a63-4a4d-93fb-7c6208d2aeab@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 08/21/09 16:31, Dan Magenheimer wrote:
> Enabling CR4_TSD only traps ring>0 rdtscs.  Trapping guest kernel
> rdtsc's is ultimately necessary because the Linux kernel does NOT
> adequately handle all the possible changes in TSC characteristics
> that can occur if Xen moves an already booted guest from one
> physical machine to another (or even from one set of pcpus
> to another on certain physical machines).  I recognize this
> is very ugly, but it may be the only way to guarantee
> correctness 100% of the time.

PV guests already correct for that by using the data Xen provides; they
don't require Xen to do any correction or synthesis of tsc values.

> The system is definitely not dead, but dom0 is busy looping or
> something.  I can probably isolate the code, but the xen
> changes seem small enough that it's hard to believe they
> could cause this kind of problem.

'0' on the Xen console will tell you where its spinning.  Oh, is it dom0
or domU?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>