From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58224 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKmZa-0007Qw-Dp for qemu-devel@nongnu.org; Tue, 23 Nov 2010 01:41:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKmZT-0003QE-PC for qemu-devel@nongnu.org; Tue, 23 Nov 2010 01:41:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKmZT-0003Py-II for qemu-devel@nongnu.org; Tue, 23 Nov 2010 01:41:43 -0500 Message-ID: <4CEB6222.5050203@redhat.com> Date: Tue, 23 Nov 2010 08:41:38 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu-kvm: introduce cpu_start/cpu_stop commands References: <1290466818-5230-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: <1290466818-5230-1-git-send-email-aliguori@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org On 11/23/2010 01:00 AM, Anthony Liguori wrote: > qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching > them to respond to these signals, introduce monitor commands that stop and start > individual vcpus. > > The purpose of these commands are to implement CPU hard limits using an external > tool that watches the CPU consumption and stops the CPU as appropriate. > > The monitor commands provide a more elegant solution that signals because it > ensures that a stopped vcpu isn't holding the qemu_mutex. > From signal(7): The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored. Perhaps this is a bug in kvm? If we could catch SIGSTOP, then it would be easy to unblock it only while running in guest context. It would then stop on exit to userspace. Using monitor commands is fairly heavyweight for something as high frequency as this. What control period do you see people using? Maybe we should define USR1 for vcpu start/stop. What happens if one vcpu is stopped while another is running? Spin loops, synchronous IPIs will take forever. Maybe we need to stop the entire process. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.