From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56789) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R72ni-0005pZ-0L for qemu-devel@nongnu.org; Fri, 23 Sep 2011 06:16:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R72ng-0001KD-RI for qemu-devel@nongnu.org; Fri, 23 Sep 2011 06:16:09 -0400 Received: from mail-ww0-f53.google.com ([74.125.82.53]:35453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R72ng-0001Js-GG for qemu-devel@nongnu.org; Fri, 23 Sep 2011 06:16:08 -0400 Received: by wwg14 with SMTP id 14so2953350wwg.10 for ; Fri, 23 Sep 2011 03:16:07 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E7C5C65.1090001@redhat.com> Date: Fri, 23 Sep 2011 12:16:05 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1315628610-28222-1-git-send-email-ronniesahlberg@gmail.com> <1315628610-28222-2-git-send-email-ronniesahlberg@gmail.com> <4E7C4E48.7030009@vnet.linux.ibm.com> In-Reply-To: <4E7C4E48.7030009@vnet.linux.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Wu Cc: qemu-devel@nongnu.org, Ronnie Sahlberg On 09/23/2011 11:15 AM, Mark Wu wrote: > I tested this patch with the following command: > x86_64-softmmu/qemu-system-x86_64 --enable-kvm rhel54_1.img -m 1024 -net > tap,ifname=tap0,script=no -net nic,model=virtio -sdl -drive > file=iscsi://127.0.0.1/iqn.2011-09.com.example:server.target1/ > And I found that the whole qemu process would get freezed, not reachable > via ping and no response on desktop if there's I/O targeted to the iscsi > drive and the iscsi target was forcefully stopped. After checking the > backtrace with gdb, I found the I/O thread got stuck on the mutex > qemu_global_mutex , which was hold by the vcpu thread. It should be > released before re-entering guest. But the vcpu thread was waiting for > the completion of iscsi aio request endlessly, and therefore couldn't > get chance to release the mutex. So the whole qemu process became > unresponsive. But this problem doesn't exist with the combination of > virtio and iscsi. Only the I/O process got hung on guest in this case. > It's more acceptable. I am not sure how to fix this problem. You don't. :( It's a problem in IDE emulation and anything else that uses qemu_aio_flush; luckily it's only called in a few places. It would be the same with NFS instead of iSCSI, for example. Otherwise, you could implement some kind of timeout+reconnect logic in the iSCSI driver or in libiscsi. Paolo