[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] rdtscp on HVM domains
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |