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] rdtscp on HVM domains

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] rdtscp on HVM domains
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 02 Dec 2009 20:30:32 +0000
Cc: Mark Langsdorf <mark.langsdorf@xxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Wed, 02 Dec 2009 12:30:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <51c65e40-01c5-4868-b343-bf2f7198533f@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpzhlSYOO7HA+JsTJukQMSIjjHmCgAB/a8c
Thread-topic: [Xen-devel] rdtscp on HVM domains
User-agent: Microsoft-Entourage/12.23.0.091001
On 02/12/2009 19:32, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> So questions for VMX/SVM experts:
> 1) Is it possible for VMX (and SVM) to allow rdtscp
>    to execute natively on machines that support it
>    without exposing the rdtscp bit in cpuid?

Yes, in fact SVM/VMX does not know how we are emulating CPUID, so that
aspect cannot affect things anyway. The issue on VMX is that by default
RDTSCP causes #UD. To stop it causing #UD you have to set the "enable
RDTSCP" flag in the VMCS (see SDM Vol3B 21.4, "RDTSCP"), which we currently
do not do, and may not be available on all systems (what happens if the flag
is not supported is not defined in the manual, but probably such CPUs do not
implement RDTSCP and so #UD will occur with no trap to the hypervisor). The
second issue for VMX is that there is only one VMEXIT control for both RDTSC
and RDTSCP. Since we must trap-and-emulate RDTSC, we cannot avoid also
trapping RDTSCP - no way we can execute it natively.

For SVM, there is a separate control for RDTSCP, and none of this nonsense
about "enable RDTSCP". Currently we trap and always emulate as #UD. But you
could execute natively, or emulate it some other way.

> 2) Is it possible for VMX (and SVM) to trap and
>    emulate rdtscp on machines that DON'T support
>    rdtscp?

Hm, probably not, since such a CPU would not know the instruction and hence
would presumably just cause #UD (undefined opcode exception) directly. And
we don't trap #UD.

 -- Keir



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

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