From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aktcv-0004dD-BU for qemu-devel@nongnu.org; Tue, 29 Mar 2016 09:24:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aktcs-0004QQ-3p for qemu-devel@nongnu.org; Tue, 29 Mar 2016 09:24:09 -0400 Received: from e06smtp08.uk.ibm.com ([195.75.94.104]:34518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aktcr-0004QD-Qh for qemu-devel@nongnu.org; Tue, 29 Mar 2016 09:24:06 -0400 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Mar 2016 14:24:04 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 137B31B08070 for ; Tue, 29 Mar 2016 14:24:35 +0100 (BST) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2TDO05A51118108 for ; Tue, 29 Mar 2016 13:24:00 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2TDNwtD000325 for ; Tue, 29 Mar 2016 07:23:59 -0600 References: <1458836125-73613-1-git-send-email-cornelia.huck@de.ibm.com> From: Christian Borntraeger Message-ID: <56FA81ED.2040903@de.ibm.com> Date: Tue, 29 Mar 2016 15:23:57 +0200 MIME-Version: 1.0 In-Reply-To: <1458836125-73613-1-git-send-email-cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/6] virtio: refactor host notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck , qemu-devel@nongnu.org Cc: tubo@linux.vnet.ibm.com, pbonzini@redhat.com, famz@redhat.com, stefanha@redhat.com, mst@redhat.com On 03/24/2016 05:15 PM, Cornelia Huck wrote: > Here's the next version of my refactoring of the virtio host notifiers. > This one actually survives a bit of testing for me (reboot loop). > > As this patchset fixes a latent bug exposed by the recent dataplane > changes (we have a deassigned ioeventfd for a short period of time > during dataplane start, which leads to the virtqueue handler being > called in both the vcpu thread and the iothread simultaneously), I'd > like to see this in 2.6. > > Changes from RFC: > - Fixed some silly errors (checking for !disabled instead of disabled, > virtio_ccw_stop_ioeventfd() calling virtio_bus_start_ioeventfd()). > - Completely reworked set_host_notifier(): We only want to set/unset > the actual handler function and don't want to do anything to the > ioeventfd backing, so reduce the function to actually doing only > that. > - With the change above, we can lose the 'assign' parameter in > virtio_bus_stop_ioeventfd() again. > - Added more comments that hopefully make it clearer what is going on. > > I'd appreciate it if people could give it some testing; I'll be back > to look at the fallout after Easter. > > Cornelia Huck (6): > virtio-bus: common ioeventfd infrastructure > virtio-bus: have callers tolerate new host notifier api > virtio-ccw: convert to ioeventfd callbacks > virtio-pci: convert to ioeventfd callbacks > virtio-mmio: convert to ioeventfd callbacks > virtio-bus: remove old set_host_notifier callback > > hw/block/dataplane/virtio-blk.c | 6 +- > hw/s390x/virtio-ccw.c | 133 ++++++++++++++-------------------------- > hw/scsi/virtio-scsi-dataplane.c | 9 ++- > hw/virtio/vhost.c | 13 ++-- > hw/virtio/virtio-bus.c | 132 +++++++++++++++++++++++++++++++++++++++ > hw/virtio/virtio-mmio.c | 128 +++++++++++++------------------------- > hw/virtio/virtio-pci.c | 124 +++++++++++++------------------------ > include/hw/virtio/virtio-bus.h | 31 +++++++++- > 8 files changed, 303 insertions(+), 273 deletions(-) > FWIW, I went back to the old F20 installation. Without your patch set qemu crashes pretty soon, with your patch set it runs stable. How intrusive would it be to provide the fix 3 times (for each transport) and do the refactoring after 2.6? If the result would be big as well I think this patch set is still the right thing to do for 2.6 unless MST has a small and beautiful 2.6fix. Christian