From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bp8op-0003qc-Ri for qemu-devel@nongnu.org; Wed, 28 Sep 2016 02:58:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bp8ok-0004JU-PX for qemu-devel@nongnu.org; Wed, 28 Sep 2016 02:58:14 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:38408 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bp8ok-0004JO-K6 for qemu-devel@nongnu.org; Wed, 28 Sep 2016 02:58:10 -0400 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8S6vRVQ024276 for ; Wed, 28 Sep 2016 02:58:10 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0b-001b2d01.pphosted.com with ESMTP id 25r7kh39ab-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Sep 2016 02:58:09 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 28 Sep 2016 07:58:08 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 37E562190023 for ; Wed, 28 Sep 2016 07:57:25 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u8S6w5tB63766728 for ; Wed, 28 Sep 2016 06:58:05 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u8S6w5AF031047 for ; Wed, 28 Sep 2016 00:58:05 -0600 References: <1474463939-12223-1-git-send-email-pbonzini@redhat.com> <1df4f6a2-f4ed-8826-823b-4a879368ccb8@redhat.com> From: Christian Borntraeger Date: Wed, 28 Sep 2016 08:58:05 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Message-Id: Subject: Re: [Qemu-devel] [PATCH 00/12] virtio: cleanup ioeventfd start/stop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: cornelia.huck@de.ibm.com, famz@redhat.com, mst@redhat.com On 09/27/2016 06:44 PM, Paolo Bonzini wrote: > > > On 27/09/2016 16:45, Christian Borntraeger wrote: >> On 09/21/2016 06:43 PM, Paolo Bonzini wrote: >>> >>> >>> On 21/09/2016 16:01, Christian Borntraeger wrote: >>>> On 09/21/2016 03:18 PM, Paolo Bonzini wrote: >>>>> This series started as an attempt to always use the dataplane path >>>>> for virtio-blk and virtio-scsi when ioeventfd is active. The aim >>>>> was three-fold: >>>>> >>>>> 1) to add more coverage for dataplane >>>>> >>>>> 2) to remove virtio_add_queue_aio >>>>> >>>>> 3) to simplify the dataplane start/stop code >>>>> >>>>> It achieves the first two objectives, and while it doesn't quite >>>>> achieve the third it does cleanup the generic ioeventfd code in >>>>> virtio-bus more than I expected. In particular, it reduces the set >>>>> of callbacks that transports must implement, and it removes the ugly >>>>> case where ioeventfd is started with generic callbacks and then moved >>>>> to the dataplane callbacks. It also enables some simplification of the >>>>> functions that deal with host notifiers. >>>>> >>>>> I've tested it with virtio-blk, virtio-scsi and vhost-net. >>>>> >>>>> Patches 1 and 2 are simplifications that are too nice to leave >>>>> them for later in the series. >>>>> >>>>> Patch 3 moves some of the ioeventfd code from virtio-bus.c to >>>>> virtio.c. At this point the transition is a bit half-assed, but >>>>> this changes as soon as we remove the generic->dataplane >>>>> handler transition. >>>>> >>>>> Patches 4 to 6 do exactly that, and then the spring cleaning >>>>> begins, lasting for the whole second half of the series. >>>>> >>>>> Opinions, reviews and bug reports? >>>> >>>> is there a branch? >>> >>> ioeventfd-virtio in my github repo. >> >> Triggering >> qemu-system-s390x: /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:771: virtio_blk_set_status: Assertion `!s->dataplane_started' failed. >> >> Is this based on the old version that still had this bug? > > No, it's a new assertion (though it looks the same as the old one), > and a stupid one too. This is hopefully enough: > > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c > index 9f09e29..52927f7 100644 > --- a/hw/block/virtio-blk.c > +++ b/hw/block/virtio-blk.c > @@ -768,7 +768,10 @@ static void virtio_blk_set_status(VirtIODevice *vdev, uint8_t status) > { > VirtIOBlock *s = VIRTIO_BLK(vdev); > > - assert(!s->dataplane_started); > + if (!(status & (VIRTIO_CONFIG_S_DRIVER | VIRTIO_CONFIG_S_DRIVER_OK))) { > + assert(!s->dataplane_started); > + } > + > if (!(status & VIRTIO_CONFIG_S_DRIVER_OK)) { > return; seems to fix the assert.