From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43719 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PL0hc-0003zZ-Ic for qemu-devel@nongnu.org; Tue, 23 Nov 2010 16:47:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PL0hb-0003ND-Cr for qemu-devel@nongnu.org; Tue, 23 Nov 2010 16:47:04 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:45438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PL0hb-0003N5-76 for qemu-devel@nongnu.org; Tue, 23 Nov 2010 16:47:03 -0500 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id oANLZ6QZ013779 for ; Tue, 23 Nov 2010 14:35:06 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oANLkx5j174588 for ; Tue, 23 Nov 2010 14:46:59 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oANLp6nE016253 for ; Tue, 23 Nov 2010 14:51:06 -0700 Message-ID: <4CEC363D.50206@linux.vnet.ibm.com> Date: Tue, 23 Nov 2010 15:46:37 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2) References: <1290530963-3448-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org, Avi Kivity On 11/23/2010 01:35 PM, Blue Swirl wrote: > On Tue, Nov 23, 2010 at 4:49 PM, Anthony Liguori wrote: > >> qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching >> them to respond to these signals (which cannot be trapped), use SIGUSR1 to >> approximate the behavior of SIGSTOP/SIGCONT. >> >> The purpose of this is to implement CPU hard limits using an external tool that >> watches the CPU consumption and stops the VCPU as appropriate. >> >> This provides a more elegant solution in that it allows the VCPU thread to >> release qemu_mutex before going to sleep. >> >> This current implementation uses a single signal. I think this is too racey >> in the long term so I think we should introduce a second signal. If two signals >> get coalesced into one, it could confuse the monitoring tool into giving the >> VCPU the inverse of it's entitlement. >> >> It might be better to simply move this logic entirely into QEMU to make this >> more robust--the question is whether we think this is a good long term feature >> to carry in QEMU? >> > >> +static __thread int sigusr1_wfd; >> > While OpenBSD finally updated the default compiler to 4.2.1 from 3.x > series, thread local storage is still not supported: > Hrm, is there a portable way to do this (distinguish a signal on a particular thread)? Regards, Anthony Liguori > $ cat thread.c > static __thread int sigusr1_wfd; > $ gcc thread.c -c > thread.c:1: error: thread-local storage not supported for this target > $ gcc -v > Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd4.8/4.2.1/specs > Target: sparc64-unknown-openbsd4.8 > Configured with: OpenBSD/sparc64 system compiler > Thread model: posix > gcc version 4.2.1 20070719 >