From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Difference between vcpu_load and kvm_sched_in ? Date: Tue, 20 Oct 2015 17:44:53 +0200 Message-ID: <56266175.4030409@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit To: Yacine , kvm@vger.kernel.org Return-path: Received: from mail-wi0-f173.google.com ([209.85.212.173]:37446 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751621AbbJTPo6 (ORCPT ); Tue, 20 Oct 2015 11:44:58 -0400 Received: by wicfv8 with SMTP id fv8so35200072wic.0 for ; Tue, 20 Oct 2015 08:44:57 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 20/10/2015 11:57, Yacine wrote: > vcpu_load; start cr3 trapping; vcpu_put > > it worked correctly (in my logs I see that vcpu.cpu become equal to "cpu = > raw_smp_processor_id();") but the VM blocks for a lot of time due to mutex > in vcpu_load (up to serveral seconds and sometimes minutes !) Right, that's because while the CPU is running the mutex is taken. If the VCPU doesn't exit, the mutex is held. > I replaced vcpu_load with kvm_sched_in, now everything works perfectly and > the VM doesn't block at all (logs here: http://pastebin.com/h5XNNMcb). > > So, what I want to know is: what is the difference between vcpu_load and > kvm_sched_in ? both of this functions call kvm_arch_vcpu_loadbut the latter > one does it without doing a mutex kvm_sched_out and kvm_sched_in are part of KVM's preemption hooks. The hooks are registered only between vcpu_load and vcpu_put, therefore they know that the mutex is taken. The sequence will go like this: vcpu_load kvm_sched_out kvm_sched_in kvm_sched_out kvm_sched_in ... vcpu_put and it will all happen with the mutex held. > Is there a problem in using kvm_sched_in instead of vcpu_load for my use case ? Yes, unfortunately it is a problem: you are loading the same VMCS on two processors, which has undefined results. To fix the problem, wrap the ioctl into a function and pass the function to QEMU's "run_on_cpu" function. It will send the ioctl from the right thread, so that the kernel will not be holding the vcpu mutex. Paolo