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: Mon, 24 Aug 2009 09:43:08 -0700
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 24 Aug 2009 09:43:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <47ab1570-28dc-4a37-96a1-44ee67ee2650@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: <47ab1570-28dc-4a37-96a1-44ee67ee2650@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/23/09 12:26, Dan Magenheimer wrote:
>> On 08/23/09 09:42, Dan Magenheimer wrote:
>>> While I'm hoping that this is true, I am skeptical.  The
>>> PV time algorithm does depend on TSC accuracy for interpolating
>>> over short intervals doesn't it?
>> Yes, it extrapolates, assuming that in the absence of power 
>> events, etc,
>> the tsc is stable over a period of a few seconds on a given CPU.
> A lot can happen in a few seconds...

That only matters if things happen that Xen doesn't know about.  If
something happens that affects the tsc's parameters, it will update them

>>> does the SMP PV guest maintain time properly?  
>> It uses timing parameters from Xen.
>> If Xen can't keep track of the tsc
>> and events which affect it and provides bad info, it will fail.
> Let's assume that Xen CAN keep track.
> How does the PV guest know if Xen's timing parameters change?
> Is it required to remember Xen's timing parameters from the last
> time it checked and compare them with this time?

No, they're in the shared info area.  It reads them afresh each time it
reads the tsc.  The info has a version counter which gets updated when
the info changes so the guest can make sure it has a consistent snapshot
of both the timing parameters and the tsc.  The timing parameters for a
given CPU are only ever updated by that CPU, so there's no risk of races
between CPUs.

BTW, kvm presents exactly the same ABI for its guests using pvclock. 
See pvclock_clocksource_read().

>> Right.  That's basically not supported under Linux, except as part of
>> certain ABIs like vgettimeofday (which is functionally 
>> identical to the
>> Xen PV clock ABI).
> Again, a shame.  I'm learning that it is not uncommon for unprivileged
> code to sample "time" tens of thousands or even hundreds of thousands
> of times per processor per second.  Trapping all app rdtscs or Linux
> going to HPET or PIT just doesn't cut it if the frequency is
> this high.  If TSC is "safe" 99.99% of the time, it sure would
> be nice if those apps could use rdtsc.

They can, with the gettimeofday vsyscall (= "syscall" which executes
entirely in usermode within a kernel-provided vsyscall page).

You're trying to make rdtsc something it isn't, even in native execution.

rdtsc represents a massive lost opportunity and failure of imagination
on Intel's part; one hopes that they'll eventually redeem themselves
with a new mechanism which does actually have all the properties one
wants - and that mechanism may eventually end up with rdtsc in it
somewhere.  But we're not really there yet, and I think trying to make
rdtsc that thing is a quixotic effort.

> I'm trying to find a solution that allows this to be supported
> in a virtual environment (without huge loss of performance).
> And I think I might have one.

Apps can't reliably use a raw rdtsc anyway, without making unwarranted
assumptions about the underlying hardware.  Any app which does may work
well on one system, but then mysteriously fail when you move it to the
backup server.

> I just got a big clue... the next line of console output in a
> successful boot AFTER the EXT3-fs mounting message is from
> the Real Time Clock Driver.  That sounds like something that
> might be affected by rdtsc changes.

Ah, yes.  It may be doing some calibration thing which never converges
with a slow rdtsc.  But that would be pretty obvious from looking at the


Xen-devel mailing list

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