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: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under Xen
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 15 Jul 2010 09:45:03 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jed Smith <jed@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 15 Jul 2010 09:45:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <b97b2105-e814-471e-b87f-0e2bc5bcbec6@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: <51C8308F-F413-47AF-8845-C92BD36CA35C@xxxxxxxxxx> <4C3E2DCC.1010201@xxxxxxxx> <alpine.DEB.2.00.1007151656380.21432@kaball-desktop 4C3F37A5.9050606@xxxxxxxx> <b97b2105-e814-471e-b87f-0e2bc5bcbec6@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5
On 07/15/2010 09:40 AM, Dan Magenheimer wrote:
> Isn't the real problem that, in a PV guest, the cpuid instructions
> that are testing the TSC-related CPUID bits are obtaining the actual
> hardware value, rather than what Xen would like the guest to believe?
>   

No, because there shouldn't be any "naked" rdtscs in the kernel.

> IOW, isn't the correct fix to use pvcpuid instead of cpuid when
> xen_pvdomain() is true?
>   

Every use of cpuid in the kernel goes via the cpuid pvop, which ends up
doing the Xen cpuid rather than the native one.  Usermode cpuid is still
the "real" one, unless they explicitly use the Xen version.

    J

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