On Sun, Nov 27, 2011 at 6:50 PM, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > On Sun, Nov 27, 2011 at 12:36:55PM +0200, Avi Kivity wrote: >> On 11/27/2011 04:42 AM, Liu Ping Fan wrote: >> > From: Liu Ping Fan <pingfank@xxxxxxxxxxxxxxxxxx> >> > >> > The vcpu can be safely released when >> > --1.guest tells us that the vcpu is not needed any longer. >> > --2.vcpu hits the last instruction _halt_ >> > >> > If both of the conditions are satisfied, kvm exits to userspace >> > with the reason vcpu dead. So the user thread can exit safely. >> > >> > >> >> Seems to be completely unnecessary. If you want to exit from the vcpu >> thread, send it a signal. >> Hi Avi and Gleb, First, I wanted to make sure my assumption is right, so I can grab your meaning more clearly -:). Could you elaborate it for me, thanks. I had thought that when a vcpu was being removed from guest, kvm must satisfy the following conditions to safely remove the vcpu: --1. The tasks on vcpu in GUEST have already been migrated to other vcpus and ONLY idle_task left ---- The CPU_DEAD is the checkpoint. --2. We must wait the idle task to hit native_halt() in GUEST, till that time, this vcpu is no needed even by idle_task. In KVM, the vcpu thread will finally sit on "kvm_vcpu_block(vcpu);" We CAN NOT suppose the sequence of the two condition because they come from different threads. Am I right? And here comes my question, --1. I think the signal will make vcpu_run exit to user, but is it allow vcpu thread to finally call "kernel/exit.c : void do_exit(long code)" in current code in kvm or in qemu? --2. If we got CPU_DEAD event, and then send a signal to vcpu thread, could we ensure that we have already sit on "kvm_vcpu_block(vcpu);" Thanks and regards, ping fan > Also if guest "tells us that the vcpu is not needed any longer" (via > ACPI I presume) and vcpu actually doing something critical instead of > sitting in 1:hlt; jmp 1b loop then it is guest's problem if it stops > working after vcpu destruction. > > -- > Gleb. > -- 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
