From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44368 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PKtHr-0006yu-4b
	for qemu-devel@nongnu.org; Tue, 23 Nov 2010 08:52:05 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PKtHk-0005Ed-KW
	for qemu-devel@nongnu.org; Tue, 23 Nov 2010 08:51:58 -0500
Received: from mail-gw0-f45.google.com ([74.125.83.45]:50389)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PKtHk-0005EQ-FW
	for qemu-devel@nongnu.org; Tue, 23 Nov 2010 08:51:52 -0500
Received: by gwj22 with SMTP id 22so1771575gwj.4
	for <qemu-devel@nongnu.org>; Tue, 23 Nov 2010 05:51:51 -0800 (PST)
Message-ID: <4CEBC6E4.1000307@codemonkey.ws>
Date: Tue, 23 Nov 2010 07:51:32 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
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>
	<4CEB6222.5050203@redhat.com>
In-Reply-To: <4CEB6222.5050203@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Chris Wright <chrisw@sous-sol.org>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org

On 11/23/2010 12:41 AM, Avi Kivity wrote:
> 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?

I need to dig deeper than.

Maybe its something about sending SIGSTOP to a process?

>
> 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.

Yeah, that's not a bad idea.

> 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.

It's the same problem if a VCPU is descheduled while another is 
running.  The problem with stopping the entire process is that a big 
motivation for this is to ensure that benchmarks have consistent results 
regardless of CPU capacity.  If you just monitor the full process, then 
one VCPU may dominate the entitlement resulting in very erratic 
benchmarking.

Regards,

Anthony Liguori