[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Tue, 06 Oct 2009 10:09:51 +0100
  • Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 06 Oct 2009 02:10:17 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcpGJo4hsYkMFCk5Q1KlfBl70CscyQALRZnAAARHiJg=
  • Thread-topic: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

On 06/10/2009 08:07, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

>> Perhaps a better choice would be for emulated tsc
>> to return Xen system time in both kernel and user
>> mode (which is what it does for HVM domains) and,
>> when a domain has tsc_native==0,
>> Xen sets its pvclock parameters so that no scaling
>> occurs?  This results in the guest reporting that
>> it has a 1GHz clock, but may be more consistent.
> Yes, this has to be fixed. There's no good reason for different TSC
> behaviours between kernel and userspace when both are emulated. If nothing
> else, when Jeremy's patches go in (which I am sure they will, as the concept
> is sane and the implementation appears so too) then that is going to be
> incompatible with emulated tsc as it behaves currently.

Should be fixed by c/s 20271.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.