[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: Live migration fails due to c/s 20627
Oops, forgot to reply to this part of your message. > > There are many cases where rdtsc/rdtscp instructions > > are emulated and so most of the code is already there. > > You only need to intercept illegal instruction traps, > > so there is not a significant performance issue. > > And the code to do the emulation is necessary > > to implement the pvrdtscp algorithm on hvm anyway > > I think in HVM environment, we should respect the native > behavior. I'm not sure why you think that. There are many many native silicon features that are not exposed directly to the guest OS. The whole point of virtualization is to present an abstract hardware interface so that multiple VMs can be supported on a single machine and VMs can be moved between underlying hardware implementations. Breaking that flexibility for a rarely utilized instruction such as rdtscp seems like a very bad idea. > Moreover, it would be valuable for > guest if it could get the node/cpu info which reflects > hardware topology. As Jeremy has pointed out, the guest OS already has other mechanisms to provide this information, and as Jun has pointed out, the non-rdtscp mechanism (lsl on Linux) may even be faster. Windows does not even provide TSC_AUX, so it definitely has other ways to obtain node/cpu info. And, as I've said before, the node/cpu info provided by Linux in TSC_AUX is wrong anyway (except in very constrained environments such as where the admin has pinned vcpus to pcpus). _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |