On Mon, Nov 28, 2011 at 03:16:01PM +0800, Liu ping fan wrote: > 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? > No, KVM can remove vcpu whenever it told to do so (may be not in the middle of emulated io though). It is a guest responsibility to eject cpu only when it is safe to do so from guest's point of view. > 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? Yes. Why not? > --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);" CPU_DEAD event is internal to a guest (one of them). KVM does not care about it. And to remove vcpu it does not have to sit in kvm_vcpu_block(). And actually since signal kicks vcpu thread out from kernel into userspace you can be sure it is not sitting in kvm_vcpu_block(). > > 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. > > -- 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
