From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEr8S-0000xT-7m for qemu-devel@nongnu.org; Sat, 15 Feb 2014 21:07:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEr8M-0001cN-C3 for qemu-devel@nongnu.org; Sat, 15 Feb 2014 21:07:12 -0500 Received: from mail-pb0-x236.google.com ([2607:f8b0:400e:c01::236]:58145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEr8L-0001c5-V8 for qemu-devel@nongnu.org; Sat, 15 Feb 2014 21:07:06 -0500 Received: by mail-pb0-f54.google.com with SMTP id uo5so13925409pbc.13 for ; Sat, 15 Feb 2014 18:07:04 -0800 (PST) Date: Sun, 16 Feb 2014 02:07:00 +0000 From: "Edgar E. Iglesias" Message-ID: <20140216020700.GA32391@amz.ap-southeast-2.compute.internal> References: <1392268034-6220-1-git-send-email-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] qom/cpu: Remove cpu->exit_request from reset state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Andreas =?iso-8859-1?Q?F=E4rber?= , pcrost@xilinx.com On Sat, Feb 15, 2014 at 03:42:56PM +0000, Peter Maydell wrote: > On 13 February 2014 05:07, wrote: > > From: "Edgar E. Iglesias" > > > > cpu->exit_request is part of the execution environment and should > > not be cleared when a CPU resets. > > > > Otherwise, we might deadlock QEMU if a CPU resets while there is > > I/O going on. > > > > Signed-off-by: Edgar E. Iglesias > > --- > > qom/cpu.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/qom/cpu.c b/qom/cpu.c > > index 9d62479..40d82dd 100644 > > --- a/qom/cpu.c > > +++ b/qom/cpu.c > > @@ -195,7 +195,6 @@ static void cpu_common_reset(CPUState *cpu) > > log_cpu_state(cpu, cc->reset_dump_flags); > > } > > > > - cpu->exit_request = 0; > > cpu->interrupt_request = 0; > > cpu->current_tb = NULL; > > cpu->halted = 0; > > This looks kind of odd to me. What's the situation you see where > this matters -- is the CPU resetting itself, or is some other device > in another thread triggering the CPU reset? TCG or KVM? Seeing this in TCG. The CPU gets signaled by the IO thread while the CPU is resetting itself. If the CPU looses the race, it clears its exit_request leaving the IO thread waiting for the global lock potentially forever. The CPU actually exits generated code but goes right back in because there is no exit_request pending. Cheers, Edgar