On Fri, May 19, 2017 at 11:54 PM, Waldek Kozaczuk <jwkozac...@gmail.com> wrote:
> What do you mean by "exit"? Is it because it calls a function? Would > inlining help? > "VMX" (virtual machine extensions) is Intel's hardware support for virtualization. What makes it efficient is that the guest code mostly runs normally (and all rings are supported), except when the guest runs certain "privileged" operations which would have allow it to escape the visualization - and in that case the hardware "exits" the guest and switches back to the hypervisor code, which is told what operation exited, and is expected to emulate this operation as it wishes. The cost of such an exit, handling, and entry is around (last time I measured) 2000 cycles, which is a big overhead for something so simple as getting the current time. By default, MSRs do exit. A hypervisor can ask the hardware NOT to exit on a certain MSR, but what this would mean is that if the guest used this MSR, the same MSR in hardware would be used. But that's not appropriate here - hyperv's clock MSR does not exist in hardware. It needs to be emulated. This is why we *need* the exit on the MSR you use in your code. The solution to avoid exit to getting the current time is to use two tricks: 1. Have the guest use the x86 TSC for short-term progress of time (VMX already can virtualize TSC without exits by applying a preset offset, without an exit) 2. Have the host write to a known place in memory (not to an MSR) information on how to convert this TSC to the actual time. This is more-or-less the tricks that the KVM paravirtual clock, XEN paravirtual clock, and apparently HyperV's "TSC page" clock, all use. Nadav. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
