From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxGb9-0004FC-2M for qemu-devel@nongnu.org; Thu, 20 Oct 2016 12:53:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxGb4-0005d1-5N for qemu-devel@nongnu.org; Thu, 20 Oct 2016 12:53:43 -0400 Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]:36077) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bxGb3-0005cX-PE for qemu-devel@nongnu.org; Thu, 20 Oct 2016 12:53:38 -0400 Received: by mail-lf0-x244.google.com with SMTP id b75so1254479lfg.3 for ; Thu, 20 Oct 2016 09:53:37 -0700 (PDT) Sender: Paolo Bonzini References: <1476100421-28772-1-git-send-email-pbonzini@redhat.com> <20161019141759.67a37694.cornelia.huck@de.ibm.com> <20161019173820.31820483.cornelia.huck@de.ibm.com> <10a6fad6-3c94-80c5-48a1-adb3e0038192@redhat.com> <20161020110355.7af28405.cornelia.huck@de.ibm.com> From: Paolo Bonzini Message-ID: Date: Thu, 20 Oct 2016 18:53:31 +0200 MIME-Version: 1.0 In-Reply-To: <20161020110355.7af28405.cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Cornelia Huck Cc: qemu-devel On 20/10/2016 11:03, Cornelia Huck wrote: > On Wed, 19 Oct 2016 22:44:18 +0200 > Paolo Bonzini wrote: > >> On 19/10/2016 17:38, Cornelia Huck wrote: >>> - failures are in qom-test for aarch64: >>> TEST: tests/qom-test... (pid=23997) >>> /aarch64/qom/integratorcp: OK >>> /aarch64/qom/nuri: OK >>> /aarch64/qom/verdex: OK >>> /aarch64/qom/ast2500-evb: OK >>> /aarch64/qom/smdkc210: OK >>> /aarch64/qom/collie: OK >>> /aarch64/qom/imx25-pdk: OK >>> /aarch64/qom/none: OK >>> /aarch64/qom/spitz: OK >>> /aarch64/qom/realview-pbx-a9: OK >>> /aarch64/qom/realview-eb: OK >>> /aarch64/qom/versatilepb: OK >>> /aarch64/qom/realview-pb-a8: OK >>> /aarch64/qom/musicpal: OK >>> /aarch64/qom/z2: OK >>> /aarch64/qom/akita: OK >>> /aarch64/qom/virt-2.7: Broken pipe >>> FAIL >>> GTester: last random seed: R02Saec62eb6f9ebd3e5bfcbf42d0aaf165a >>> (pid=24053) >>> /aarch64/qom/kzm: OK >>> /aarch64/qom/virt-2.8: Broken pipe >>> FAIL >>> GTester: last random seed: R02S3472a1653451d1812262f7d72624492e >>> (pid=24063) >>> /aarch64/qom/realview-eb-mpcore: OK >>> /aarch64/qom/sx1: OK >>> /aarch64/qom/sx1-v1: OK >>> /aarch64/qom/virt-2.6: Broken pipe >>> FAIL >>> GTester: last random seed: R02Se4b753c5be66c0ef7870bebcca8771f8 >>> (pid=24098) >>> /aarch64/qom/cubieboard: OK >>> /aarch64/qom/highbank: OK >>> /aarch64/qom/raspi2: OK >>> /aarch64/qom/netduino2: OK >>> /aarch64/qom/terrier: OK >>> /aarch64/qom/n810: OK >>> /aarch64/qom/mainstone: OK >>> /aarch64/qom/palmetto-bmc: OK >>> /aarch64/qom/sabrelite: OK >>> /aarch64/qom/midway: OK >>> /aarch64/qom/cheetah: OK >>> /aarch64/qom/tosa: OK >>> /aarch64/qom/borzoi: OK >>> /aarch64/qom/versatileab: OK >>> /aarch64/qom/lm3s6965evb: OK >>> /aarch64/qom/n800: OK >>> /aarch64/qom/connex: OK >>> /aarch64/qom/xilinx-zynq-a9: OK >>> /aarch64/qom/xlnx-ep108: OK >>> /aarch64/qom/vexpress-a9: Broken pipe >>> FAIL >>> GTester: last random seed: R02Sdf4aceaaef3ceb060fd5996ecfd05bbb >>> (pid=24180) >>> /aarch64/qom/vexpress-a15: Broken pipe >>> FAIL >>> GTester: last random seed: R02Sdf4de27065ea3baf0b2acc109af636b8 >>> (pid=24187) >>> /aarch64/qom/xlnx-zcu102: OK >>> /aarch64/qom/canon-a1100: OK >>> /aarch64/qom/lm3s811evb: OK >>> FAIL: tests/qom-test >>> >>> Do these boards maybe have something interesting in common? >>> >>> No further time to look into this today, sorry. >> >> They use virtio-mmio, probably. I'll look at it tomorrow. >> >> The s390 spew is an abort(), isn't it? >> Paolo >> > > virtio-mmio looks like the best candidate (maybe the eventfd is not > stopped properly and writes happen where they are not supposed to > anymore?) But staring at the patch didn't make anything jump out at > me... No, it's because virtio-mmio can be created without a device underneath. virtio_bus_start_ioeventfd in that case is wrong, but virtio_bus_stop_ioeventfd should be a no-op. The fix is trivial: diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c index 0479704..bf61f66 100644 --- a/hw/virtio/virtio-bus.c +++ b/hw/virtio/virtio-bus.c @@ -172,12 +172,15 @@ int virtio_bus_start_ioeventfd(VirtioBusState *bus) void virtio_bus_stop_ioeventfd(VirtioBusState *bus) { - VirtIODevice *vdev = virtio_bus_get_device(bus); - VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev); + VirtIODevice *vdev; + VirtioDeviceClass *vdc; if (!bus->ioeventfd_started) { return; } + + vdev = virtio_bus_get_device(bus); + vdc = VIRTIO_DEVICE_GET_CLASS(vdev); vdc->stop_ioeventfd(vdev); bus->ioeventfd_started = false; } I'll post v3 tomorrow. Paolo