> What about preemption: > > - vcpu executes lapic code in qemu process context
Don't understand. LAPIC is in kernel, how can qemu access? If you mean qemu is calling APIC KVM syscall, then it already disabled preemption & take kvm->lock. > - process is preempted > - timer fires, touches lapic code See above. > > Furthermore, I question the necessity of this. Taking a spinlock is a > couple dozen cycles on modern processors. Entering the guest is a > couple thousand. So what are we saving? I am stuck, can u explain more? We didn't enter guest more than before. > > (migrating the timer is a good thing though). > > A different approach might be to wake up the vcpu like we do for irr, > with kvm_vcpu_kick(), and let the timer code be handled in process > context, so no locks need be taken. > This can be too, but will that be much efficient than timer migration? Usually the guest APIC timer is around 1ms, which means we have to VM Exit guest 1000HZ with cost of thousands of cycles each time. While the process migration can only happen at scheduler quantum (10ms?) and highly depend on the scheduler policy. I guess the cost of hrtimer migration won;t exceed 1000 cycles in modern processor. And today the migration cost is already exceeds hundreds of cycles, add this additional one won;t change many. So I think the cost using hrtimer migration is much cheap than kvm_vcpu_kick(), but I may miss something. Eddie ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
