From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40704 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfdNu-0006hG-W7 for qemu-devel@nongnu.org; Wed, 19 Jan 2011 14:08:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfdIg-0003WY-2H for qemu-devel@nongnu.org; Wed, 19 Jan 2011 14:02:35 -0500 Received: from mail-ew0-f45.google.com ([209.85.215.45]:42194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfdIf-0003WK-Nw for qemu-devel@nongnu.org; Wed, 19 Jan 2011 14:02:34 -0500 Received: by ewy10 with SMTP id 10so722685ewy.4 for ; Wed, 19 Jan 2011 11:02:32 -0800 (PST) Date: Wed, 19 Jan 2011 20:02:28 +0100 From: "Edgar E. Iglesias" Message-ID: <20110119190228.GA18679@laped.lan> References: <20110117100308.GA12308@edde.se.axis.com> <20110118001950.GA11802@laped.lan> <4D3564D9.6020104@siemens.com> <20110119170226.GA11614@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110119170226.GA11614@amt.cnet> Subject: [Qemu-devel] Re: MIPS, io-thread, icount and wfi List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Jan Kiszka , qemu-devel@nongnu.org, kvm On Wed, Jan 19, 2011 at 03:02:26PM -0200, Marcelo Tosatti wrote: > On Tue, Jan 18, 2011 at 11:00:57AM +0100, Jan Kiszka wrote: > > On 2011-01-18 01:19, Edgar E. Iglesias wrote: > > > On Mon, Jan 17, 2011 at 11:03:08AM +0100, Edgar E. Iglesias wrote: > > >> Hi, > > >> > > >> I'm running an io-thread enabled qemu-system-mipsel with icount. > > >> When the guest (linux) goes to sleep through the wait insn (waiting > > >> to be woken up by future timer interrupts), the thing deadlocks. > > >> > > >> IIUC, this is because vm timers are driven by icount, but the CPU is > > >> halted so icount makes no progress and time stands still. > > >> > > >> I've locally disabled vcpu halting when icount is enabled, that > > >> works around my problem but of course makes qemu consume 100% host cpu. > > >> > > >> I don't know why I only see this problem with io-thread builds? > > >> Could be related timing and luck. > > >> > > >> Would be interesting to know if someone has any info on how this was > > >> intended to work (if it was)? And if there are ideas for better > > >> workarounds or fixes that don't disable vcpu halting entirely. > > > > > > Hi, > > > > > > I've found the problem. For some reason io-thread builds use a > > > static timeout for wait loops. The entire chunk of code that > > > makes sure qemu_icount makes forward progress when the CPU's > > > are idle has been ifdef'ed away... > > > > > > This fixes the problem for me, hopefully without affecting > > > io-thread runs without icount. > > > > > > commit 0f4f3a919952500b487b438c5520f07a1c6be35b > > > Author: Edgar E. Iglesias > > > Date: Tue Jan 18 01:01:57 2011 +0100 > > > > > > qemu-timer: Fix timeout calc for io-thread with icount > > > > > > Make sure we always make forward progress with qemu_icount to > > > avoid deadlocks. For io-thread, use the static 1000 timeout > > > only if icount is disabled. > > > > > > Signed-off-by: Edgar E. Iglesias > > > > > > diff --git a/qemu-timer.c b/qemu-timer.c > > > index 95814af..db1ec49 100644 > > > --- a/qemu-timer.c > > > +++ b/qemu-timer.c > > > @@ -110,7 +110,6 @@ static int64_t cpu_get_clock(void) > > > } > > > } > > > > > > -#ifndef CONFIG_IOTHREAD > > > static int64_t qemu_icount_delta(void) > > > { > > > if (!use_icount) { > > > @@ -124,7 +123,6 @@ static int64_t qemu_icount_delta(void) > > > return cpu_get_icount() - cpu_get_clock(); > > > } > > > } > > > -#endif > > > > > > /* enable cpu_get_ticks() */ > > > void cpu_enable_ticks(void) > > > @@ -1077,9 +1075,17 @@ void quit_timers(void) > > > > > > int qemu_calculate_timeout(void) > > > { > > > -#ifndef CONFIG_IOTHREAD > > > int timeout; > > > > > > +#ifdef CONFIG_IOTHREAD > > > + /* When using icount, making forward progress with qemu_icount when the > > > + guest CPU is idle is critical. We only use the static io-thread timeout > > > + for non icount runs. */ > > > + if (!use_icount) { > > > + return 1000; > > > + } > > > +#endif > > > + > > > if (!vm_running) > > > timeout = 5000; > > > else { > > > @@ -1110,8 +1116,5 @@ int qemu_calculate_timeout(void) > > > } > > > > > > return timeout; > > > -#else /* CONFIG_IOTHREAD */ > > > - return 1000; > > > -#endif > > > } > > > > > > > > > > > > > This logic and timeout values were imported on iothread merge. And I bet > > at least the timeout value of 1s (vs. 5s) can still be found in > > qemu-kvm. Maybe someone over there can remember the rationales behind > > choosing this value. > > > > Jan > > This timeout is for the main select() call. So there is not a lot > of reasoning, how long to wait when there's no activity on the file > descriptors. OK, I suspected something like that. Thanks both of you for the info. I'll give people a couple of days to complain at the patch, if noone does I'll apply it. Cheers