From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUwrU-0007Ku-Q2 for qemu-devel@nongnu.org; Mon, 28 Nov 2011 03:46:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUwrP-0001Ma-3s for qemu-devel@nongnu.org; Mon, 28 Nov 2011 03:46:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUwrO-0001MR-OI for qemu-devel@nongnu.org; Mon, 28 Nov 2011 03:46:47 -0500 Date: Mon, 28 Nov 2011 10:46:43 +0200 From: Gleb Natapov Message-ID: <20111128084643.GP2557@redhat.com> References: <1322188529-11609-1-git-send-email-kernelfans@gmail.com> <1322361735-21428-1-git-send-email-kernelfans@gmail.com> <4ED212C7.1080901@redhat.com> <20111127105000.GL2557@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 2/2] kvm: exit to userspace with reason KVM_EXIT_VCPU_DEAD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liu ping fan Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, ryanh@us.ibm.com, jan.kiszka@web.de, Avi Kivity 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 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 > >> > > >> > 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. =9AIf you want to exit from the vc= pu > >> thread, send it a signal. > >> > Hi Avi and Gleb, >=20 > 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. >=20 > 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? >=20 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().=20 >=20 > Thanks and regards, > ping fan >=20 > > 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. > > >=20 >=20 > > -- > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9AGleb. > > -- Gleb.