WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [PATCH] softtsc (was RE: [Xen-devel] Guest TSC and Xen (Intel and AM

To: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>, "Zhang, Li" <li.zhang@xxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] softtsc (was RE: [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please))
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 10 Jul 2008 15:29:56 +0100
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Delivery-date: Thu, 10 Jul 2008 07:30:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080710081931031.00000003744@djm-pc>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjboIivPTuddHlLSIGPaPhte5VM5wASModQADA1FBAAMHiVIAAjyGRgAKf/8qAAAXmfcAABT0gwAABianAAB1i/gAAAqGFQAAV3jZAAHxjV8AAr0sqQABkkb9UACeStgAAA97vu
Thread-topic: [PATCH] softtsc (was RE: [Xen-devel] Guest TSC and Xen (Intel and AMD feedback please))
User-agent: Microsoft-Entourage/11.4.0.080122
Hmm.. okay I think I will throw away the debug-output pieces of the patch.
They are logically separate and distinct anyway.

 -- Keir

On 10/7/08 15:19, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

>> Yes, I will take it, but have the following comments.
>>  2. Your change in common/keyhandler.c breaks ia64. :-)
> 
> Oops! ;-)  What's the best way to handle this?  It would
> be unfortunate to lose valuable debug data just because its
> arch-dependent but I don't see any other arch-dependent code
> in keyhandler.c and I'll bet you don't want to start adding
> ifdef's nor introduce arch/xxx/keyhandler.c just for this.
> 
>>  1. Why do you define new boolean 'constant_tsc'? Can you just use
>> test_bit(X86_FEATURE_CONSTANT_TSC)?
>>  3. Your change to arch/x86/time.c looks unnecessary.
> 
> I was thinking that the tests for these features should probably
> be abstracted (e.g. static inline in a header file or a
> global function), but wasn't sure about the best way to deal
> with the datatypes (e.g. struct cpuinfo_x86) so defaulted to
> global variables.
> 
> Both globals are simply for debug output in keyhandler.c
> so depending on the answer to (2) above, those patch-parts
> could just go away.
> 
>>  4. Should you catch SVM's RDTSCP vmexit as well as RDTSC?
> 
> I thought I remembered seeing code that reported/lied to guests
> that the rdtscp feature was not present?
> 
> Thanks,
> Dan
> 



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