From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3in4-0008Lx-En for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:22:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T3imr-00062E-Bf for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:22:18 -0400 Received: from david.siemens.de ([192.35.17.14]:25811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T3imr-00061e-1g for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:22:05 -0400 Message-ID: <50333717.6050207@siemens.com> Date: Tue, 21 Aug 2012 09:21:59 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4FEC56B2.6050502@dlhnet.de> <502E42E9.2020402@siemens.com> <502E56D3.6060607@siemens.com> <502E5800.5060609@siemens.com> <502E5D66.1060003@siemens.com> <5030B51E.3010704@redhat.com> In-Reply-To: <5030B51E.3010704@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Stefan Hajnoczi , Peter Lieven , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Paolo Bonzini On 2012-08-19 11:42, Avi Kivity wrote: > On 08/17/2012 06:04 PM, Jan Kiszka wrote: >> >>>> Can anyone imagine that such a barrier may actually be required? If it >>>> is currently possible that env->stop is evaluated before we called into >>>> sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the >>>> signal without properly processing its reason (stop). >> >> Should not be required (TM): Both signal eating / stop checking and stop >> setting / signal generation happens under the BQL, thus the ordering >> must not make a difference here. > > Agree. > > >> Don't see where we could lose a signal. Maybe due to a subtle memory >> corruption that sets thread_kicked to non-zero, preventing the kicking >> this way. > > Cannot be ruled out, yet too much of a coincidence. > > Could be a kernel bug (either in kvm or elsewhere), we've had several > before in this area. > > Is this reproducible? Not for me. Peter only hit it very rarely, Peter obviously more easily. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux