[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 08:07:19 +0100
  • Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 06 Oct 2009 00:07:43 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcpGJo4hsYkMFCk5Q1KlfBl70CscyQALRZnA
  • Thread-topic: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

On 06/10/2009 02:43, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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