Hi Paolo, On Tue, Dec 17, 2013 at 8:28 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Il 17/12/2013 12:43, Arthur Chunqi Li ha scritto: >> Hi Paolo, >> >> Thanks very much. And...(see below) >> >> On Tue, Dec 17, 2013 at 7:21 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> Il 17/12/2013 07:11, Arthur Chunqi Li ha scritto: >>>> Hi Paolo, >>>> >>>> Since VCPU is managed the same as a process in kernel, how can I know >>>> the status (running, sleeping etc.) of a vcpu in kernel? Is there a >>>> variant in struct kvm_vcpu or something else indicate this? >>> >>> waitqueue_active(&vcpu->wq) means that the VCPU is sleeping in the >>> kernel (i.e. in a halted state). >>> >>> vcpu->mode == IN_GUEST_MODE means that the VCPU is running. >>> >>> Anything else means that the host is running some kind of "glue" code >>> (either kernel or userspace). >> >> Another question about scheduler. When I have 4 vcpus and the workload >> of VM is low, and I noticed that it tends to activate only 1 or 2 >> vcpus. Does this mean the other 2 vcpus are scheduled out or into >> sleeping status? > > This depends on what the guest scheduler is doing. The other 2 VCPUs > are probably running for so little time (a few microseconds every > 1/100th of a second) that you do not see them, and they stay halted the > rest of the time. > > Remember that KVM has no scheduler of its own. What you see is the > combined result of the guest and host schedulers. >>> >>>> Besides, if vcpu1 is running on pcpu1, and a kernel thread running on >>>> pcpu0. Can the kernel thread send a message to force vcpu1 trap to >>>> VMM? How can I do this? >>> >>> Yes, with kvm_vcpu_kick. KVM tracks internally which pcpu will run the >>> vcpu in vcpu->cpu, and kvm_vcpu_kick sends either a wakeup (if the vcpu >>> is sleeping) or an IPI (if it is running). >> >> What is vcpu's action if kvm_vcpu_kick(vcpu)? What is the exit_reason >> of the kicked vcpu? > > No exit reason, you just get a lightweight exit to the host kernel. If > you want a userspace exit, you'd need to set a bit in vcpu->requests > before kvm_vcpu_kick (which you can do best with kvm_make_request), and > change that to a userspace exit in vcpu_enter_guest. There's already an > example of that, search arch/x86/kvm/x86.c for KVM_REQ_TRIPLE_FAULT. I failed to kvm_vcpu_kick inactive vcpus at the beginning of the boot time (from power up to grub) of a VM. I think this may because other vcpus are not activated by SMP system at boot time, right? How can I distinguish vcpus in such status? Thanks, Arthur > > Paolo -- Arthur Chunqi Li Department of Computer Science School of EECS Peking University Beijing, China -- 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
