From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop Date: Sun, 19 Aug 2012 12:42:54 +0300 Message-ID: <5030B51E.3010704@redhat.com> References: <4FEC56B2.6050502@dlhnet.de> <502E42E9.2020402@siemens.com> <502E56D3.6060607@siemens.com> <502E5800.5060609@siemens.com> <502E5D66.1060003@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , Peter Lieven , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Paolo Bonzini To: Jan Kiszka Return-path: In-Reply-To: <502E5D66.1060003@siemens.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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? -- error compiling committee.c: too many arguments to function