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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] rdtscp on HVM domains
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 3 Dec 2009 15:26:31 -0800 (PST)
Cc: Mark Langsdorf <mark.langsdorf@xxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Thu, 03 Dec 2009 15:28:06 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C73C7EE8.35E8%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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
So it doesn't look impossible, but probably not easy either.

Well, although HVM support for pvrdtscp would be nice
to have, I guess we can live without it for the foreseeable
future.  If KVM wants to implement pvrdtscp support
though, they will have to deal with this.

> > 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

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