Re: [Xen-devel] rdtscp on HVM domains

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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