Il 05/09/2013 11:24, Zhang, Yang Z ha scritto: > > Here I have such consideration: this logic is wrong if CPU support > > PIN_BASED_VMX_PREEMPTION_TIMER but doesn't support > > VM_EXIT_SAVE_VMX_PREEMPTION_TIMER, though I don't know if this does > > occurs. So the codes above reads the MSR and reserves the features it > > supports, and here I just check if these two features are supported > > simultaneously. > > No. Only VM_EXIT_SAVE_VMX_PREEMPTION_TIMER depends on > PIN_BASED_VMX_PREEMPTION_TIMER. PIN_BASED_VMX_PREEMPTION_TIMER is an > independent feature Not for the current implementation of the preemption timer in nested VMX. In order to emulate PIN_BASED_VMX_PREEMPTION_TIMER, you need to decrement the preemption timer in vmcs02 whenever you have an L2->L0->L2 exit. The current implementation chooses to use VM_EXIT_SAVE_VMX_PREEMPTION_TIMER to do this decrement. It is possible to not use it. As the Intel SDM says (31.13), "the VMM may use another timer (e.g. the TSC) to track the amount of time the VM has run while still using the VMX-preemption timer for VM preemption. In this scenario the VMM would not save the VMX-preemption timer on each VM-exit but instead would reload the VMX-preemption timer with initial VM quantum less the time the VM has already run. This scenario includes all the VM-entry and VM-exit latencies in the VM run time". In fact, perhaps it's even a better choice, but for Arthur's code it is correct to depend on VM_EXIT_SAVE_VMX_PREEMPTION_TIMER. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
