RE: [Xen-devel] rdtscp on HVM domains

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel