| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] rdtscp on HVM domains
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
|
|
|
| |
|
Home