On Mon, 6 Jun 2016 15:49:12 +0200 Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 04/06/2016 02:24, yunhong jiang wrote: > >> > 2) if possible, I would like to remove kvm_lapic_arm_hv_timer. > >> > Instead, make switch_to_hv_lapic_timer and start_apic_timer can > >> > call kvm_x86_ops->set_hv_timer, passing the desired *guest* TSC. > >> > set_hv_timer can convert the guest TSC to a host TSC and save the > >> > desired host TSC in struct vmx_vcpu. vcpu_run checks if there > >> > is a > > Hi, Paolo, I mostly finished my patch, but one thing come to my > > mind in the last minutes and hope to get your input. > > One issue to save the host TSC on the vmx_vcpu is, if the vCPU > > thread is migrated to another pCPU, and the TSC are not > > synchronized between these two pCPUs, then the result is not > > accurate. In previous patchset, it's ok because we do the > > calculation on the vcpu_run() thus the migration does not matter. > > My suggestion here is to redo the vmx_set_hv_timer in vmx_vcpu_load. > > It should fix the 32-bit overflow below, too. > > Paolo Aha, good point. Will do this way. And will remove the "RFC" on next patchset. Thanks --jyh > > > This also bring a tricky situation considering the VMX preepmtion > > timer can only hold 32bit value. In a rare situation, the host > > delta TSC is less than 32 bit, however, if there is a host tsc > > backwards after the migration, then the delta TSC on the new CPU > > may be larger than 32 bit, but we can't switch back to sw timer > > anymore because it's too late. I add some hacky code on the > > kvm_arch_vcpu_load(), not sure if it's ok. > > > > I will send a RFC patch. I'm still looking for a > > platform with TSC scaling support, thus not test TSC scaling > > yet. Others has been tested. > > -- 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
