From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdIIF-0003ER-KI for qemu-devel@nongnu.org; Wed, 01 Apr 2015 09:02:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdIIB-0005qv-DP for qemu-devel@nongnu.org; Wed, 01 Apr 2015 09:02:51 -0400 Received: from mailpro.odiso.net ([89.248.209.98]:49173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdIIB-0005qa-8P for qemu-devel@nongnu.org; Wed, 01 Apr 2015 09:02:47 -0400 Date: Wed, 1 Apr 2015 15:02:45 +0200 (CEST) From: Alexandre DERUMIER Message-ID: <942876039.31520507.1427893365117.JavaMail.zimbra@oxygem.tv> In-Reply-To: <551BC80F.9040702@redhat.com> References: <173593231.25820090.1427859280478.JavaMail.zimbra@oxygem.tv> <551BC80F.9040702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] virtio-scsi + iothread : segfault on drive_del List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: pbonzini Cc: qemu-devel Ok, thanks paolo ! ----- Mail original ----- De: "pbonzini" =C3=80: "aderumier" , "qemu-devel" Envoy=C3=A9: Mercredi 1 Avril 2015 12:27:27 Objet: Re: virtio-scsi + iothread : segfault on drive_del On 01/04/2015 05:34, Alexandre DERUMIER wrote:=20 >=20 > I'm currently testing virtio-scsi and iothread,=20 >=20 > and I'm seeing qemu segfault when I try to remove an scsi drive=20 > on top of an virtio-scsi controller with iothread enabled.=20 >=20 >=20 > virtio-blk + iothread drive_del is supported since this patch=20 >=20 > http://comments.gmane.org/gmane.comp.emulators.qemu/291562=20 > "block: support drive_del with dataplane=20 >=20 > This series makes hot unplug work with virtio-blk dataplane devices. It s= hould=20 > also work with Fam's virtio-scsi dataplane patches."=20 virtio-scsi + iothread is experimental and not yet thread-safe.=20 Deadlocks or crashes are expected, and not really fixable without a lot=20 of preparatory changes to core QEMU code. These are being done, but I=20 don't expect it to be fixed before 2.5.=20 Paolo=20