I''ve just discovered that the rdtscp instruction doesn''t work at all in a VMX (Intel HVM) domain, even on a Nehalem physical machine that supports the rdtscp instruction in hardware. (I don''t have an AMD machine handy to test... reading the code it appears to me it won''t work there either, but I''m not positive.) Since Xen doesn''t expose the rdtscp bit in cpuid, this may make sense, but the pvrdtscp algorithm asks Xen directly whether the physical machine supports rdtscp and then uses the rdtscp instruction if Xen answers yes. Ideally, we''d like to allow these enterprise apps to work (fast and correctly) both on PV and HVM. 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? 2) Is it possible for VMX (and SVM) to trap and emulate rdtscp on machines that DON''T support rdtscp? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 02/12/2009 19:32, "Dan Magenheimer" <dan.magenheimer@oracle.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel