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] RE: TSC scaling and softtsc reprise, and PROPOSAL

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: TSC scaling and softtsc reprise, and PROPOSAL
From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Date: Tue, 28 Jul 2009 09:46:32 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 27 Jul 2009 18:47:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0c710224-7206-4305-9e2c-dc2f8e4099be@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: <4FA716B1526C7C4DB0375C6DADBC4EA341740F5E68@xxxxxxxxxxxxxxxxxxxxxxxxx> <0c710224-7206-4305-9e2c-dc2f8e4099be@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoOyUZduznbP3wfRcWQ2ko3MyE0nQAV0lKw
Thread-topic: TSC scaling and softtsc reprise, and PROPOSAL
Dan Magenheimer wrote:
>>> Can someone at Intel confirm or deny that VMware ESX
>>> always traps rdtsc?  If so, it is probably not hard
>>> to write an application that works on VMware ESX (on
>>> certain hardware) but fails on Xen.
>> I'd be rather surprised if VMware trapped RDTSC. From what I
>> gather, ESX3 doesn't make a great deal of use of VT for 32b
>> guests, so at the very least it would be tricky to do
>> anything about user space use of rdtsc.
> Some googling and reading provides evidence that VMware
> does indeed virtualize the TSC.  The timekeeping paper
> http://www.vmware.com/pdf/vmware_timekeeping.pdf
> tells how to turn vTSC off, but says that turning it
> off is no longer recommended.  The ASPLOS paper
> http://www.vmware.com/pdf/asplos235_adams.pdf
> uses rdtsc as an example of how binary translation
> is much faster than emulation or callout (though
> their BT version fetches a stale TSC which afaict
> doesn't solve the ordering problem).
> Also, Avi Kivity tells me that the KVM folks have
> also recently come to the conclusion that it is necessary
> to emulate TSC, though KVM currently does not. 

Hi, Dan 
   I am still confused about why need to emulate rdtsc is necessary. Even if 
emulating it in software, we still need to find a stable time source, right?  
If you think TSC is not stable on SMP system, and I think the issue should 
exist in native OS which depends on TSC as time source instead of Xen-self 
issue.  If host's TSC is stable enough, I think the hardware's TSC offset 
feature should be the right way to go ?  

I have a proposal on it. If Xen finds hardware's TSC is not reliable, it can 
tell guest about the info at guest's boot stage, and guest should use other  
time sources(eg, hpet) instead of TSC . And if the TSC is reliable in hardware, 
I think we should let Xen try the best to use hardware's feature and just leave 
it as current implementation. If users know hardware's TSC is not reliable from 
his knowledge, it may set softtsc to solve the possible issue manually.  So 
maybe we only need to create a way how to tell guest the TSC's status in Xen 

Xen-devel mailing list

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