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


Re: [Xen-devel] [PATCH] Implement rdtscp emulation and rdtscp_aux "suppo

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Implement rdtscp emulation and rdtscp_aux "support"
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 26 Nov 2009 10:26:48 +0000
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 26 Nov 2009 02:27:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C733FB78.2D4C%keir.fraser@xxxxxxxxxxxxx>
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: <4B0E471E0200007800022289@xxxxxxxxxxxxxxxxxx> <C733FB78.2D4C%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 26.11.09 10:31 >>>
>On 26/11/2009 08:15, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> I realize that my comment really applies to your earlier patch introducing
>> rdtsc emulation, but somehow that aspect slipped my attention back
>> then: Linux has, as a security option, a mechanism to disable rdtsc for
>> apps, but your emulation code doesn't honor the guest setting of
>> CR4.TSD.
>I'll fix this. While I'm at it, I think our PV emulation of MOV CR4,reg is
>broken -- should just return v->arch.guest_context.ctrlreg[4], would you
>agree? Otherwise guest's CR4.TSD isn't returned.

Indeed, with the real bit no longer necessarily being in sync with the
guest specified one simply reading the physical register doesn't work
anymore. I'm somewhat uncertain about returning
v->arch.guest_context.ctrlreg[4] though, since there should have
been a reason we used the more expensive read of the real register
(but looking at the code I can't determine that hypothetical reason).


Xen-devel mailing list