From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5X3a-0004gx-Mo for qemu-devel@nongnu.org; Fri, 11 Jul 2014 05:24:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5X3T-0000VW-5p for qemu-devel@nongnu.org; Fri, 11 Jul 2014 05:23:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5X3S-0000Uq-R3 for qemu-devel@nongnu.org; Fri, 11 Jul 2014 05:23:47 -0400 Date: Fri, 11 Jul 2014 11:23:34 +0200 From: Stefan Hajnoczi Message-ID: <20140711092334.GA25216@stefanha-thinkpad.redhat.com> References: <53BFA6AC.1090204@de.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <53BFA6AC.1090204@de.ibm.com> Subject: Re: [Qemu-devel] block device fd consuption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: Cornelia Huck , "qemu-devel@nongnu.org" , Dominik Dingel --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 11, 2014 at 10:56:12AM +0200, Christian Borntraeger wrote: > Stefan, >=20 > I traced the creation of eventfds with gdb in the case of virtio-blk. Great, thanks for posting this! Most of these eventfds are "justified". They are actively used and are not leaked. Avoiding them might be possible with some work but is likely to make the code messier or notification more expensive (e.g. we have to scan more request structs to check for completion). But see the thread pool case below where I think we can eliminate the eventfd. > With the following setup > qemu-system-s390x -enable-kvm -m 1000 -nographic -kernel /boot/vmlinux-3.= 15.0+ -initrd ramdisk -smp 2 -append "root=3D/dev/ram0" -M s390-ccw -drive = file=3D/dev/sdc,if=3Dnone,id=3Dd0,format=3Draw,serial=3Dd0,cache=3Dnone,aio= =3Dnative -device virtio-blk-ccw,drive=3Dd0,x-data-plane=3Don,config-wce=3D= off,scsi=3Doff >=20 > In addition to the file descriptor for the device itself I have the follo= wing eventfd: >=20 >=20 > Breakpoint 1, event_notifier_init (e=3De@entry=3D0x807e8f24, active=3Dact= ive@entry=3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #0 event_notifier_init (e=3De@entry=3D0x807e8f24, active=3Dactive@entry= =3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #1 0x000000008019e766 in aio_context_new () at /home/cborntra/REPOS/qemu= /async.c:274 > #2 0x00000000801ae628 in qemu_init_main_loop () at /home/cborntra/REPOS/= qemu/main-loop.c:142 > #3 0x000000008001598c in main (argc=3D, argv=3D0x3fffffff= 2c8, envp=3D) at /home/cborntra/REPOS/qemu/vl.c:3972 > --> main loop: this is ok and not related to virtio-blk. Yes. > Breakpoint 1, event_notifier_init (e=3De@entry=3D0x807fed48, active=3Dact= ive@entry=3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #0 event_notifier_init (e=3De@entry=3D0x807fed48, active=3Dactive@entry= =3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #1 0x00000000801ebb58 in laio_init () at /home/cborntra/REPOS/qemu/block= /linux-aio.c:289 > #2 0x00000000801ea17a in raw_set_aio (aio_ctx=3D0x807fa0a8, use_aio=3D0x= 807fa0a0, bdrv_flags=3D) at /home/cborntra/REPOS/qemu/block/= raw-posix.c:351 > #3 0x00000000801ea2a2 in raw_open_common (bs=3Dbs@entry=3D0x807fd1a0, op= tions=3Doptions@entry=3D0x807fdce0, bdrv_flags=3Dbdrv_flags@entry=3D24802, = open_flags=3Dopen_flags@entry=3D0, errp=3Derrp@entry=3D0x3ffffffd698) > at /home/cborntra/REPOS/qemu/block/raw-posix.c:433 > #4 0x00000000801ea6b4 in hdev_open (bs=3D0x807fd1a0, options=3D0x807fdce= 0, flags=3D, errp=3D0x3ffffffe830) at /home/cborntra/REPOS/q= emu/block/raw-posix.c:1760 > #5 0x00000000801aba9e in bdrv_open_common (errp=3D0x3ffffffe818, drv=3D0= x80316088 , flags=3D57570, options=3D0x807fdce0, file=3D0= x0, bs=3D0x807fd1a0) at /home/cborntra/REPOS/qemu/block.c:967 > #6 bdrv_open (pbs=3Dpbs@entry=3D0x3ffffffe9e0, filename=3D, filename@entry=3D0x807fa300 "/dev/disk/by-id/scsi-36005076305ffc1ae", '0= ' , "2580", reference=3Dreference@entry=3D0x0,=20 > options=3D0x807fdce0, flags=3D57570, drv=3D0x80316088 , errp=3D0x3ffffffe9e8) at /home/cborntra/REPOS/qemu/block.c:1472 > #7 0x00000000801ac460 in bdrv_open_image (pbs=3Dpbs@entry=3D0x3ffffffe9e= 0, filename=3Dfilename@entry=3D0x807fa300 "/dev/disk/by-id/scsi-36005076305= ffc1ae", '0' , "2580",=20 > options=3Doptions@entry=3D0x807fb160, bdref_key=3Dbdref_key@entry=3D0= x8027a526 "file", flags=3Dflags@entry=3D57570, allow_none=3Dtrue, errp=3D0x= 3ffffffe9e8) at /home/cborntra/REPOS/qemu/block.c:1274 > #8 0x00000000801ab74a in bdrv_open (pbs=3Dpbs@entry=3D0x807fa5b0, filena= me=3Dfilename@entry=3D0x807fa300 "/dev/disk/by-id/scsi-36005076305ffc1ae", = '0' , "2580", reference=3Dreference@entry=3D > 0x0, options=3D0x807fb160, options@entry=3D0x807f8ce0, flags=3D8418, = flags@entry=3D226, drv=3D0x80312908 , errp=3D0x3ffffffead8) at /h= ome/cborntra/REPOS/qemu/block.c:1451 > #9 0x00000000800ba11e in blockdev_init (file=3Dfile@entry=3D0x807fa300 "= /dev/disk/by-id/scsi-36005076305ffc1ae", '0' , "2580", bs= _opts=3Dbs_opts@entry=3D0x807f8ce0, errp=3Derrp@entry=3D > 0x3ffffffec58) at /home/cborntra/REPOS/qemu/blockdev.c:523 > #10 0x00000000800bb530 in drive_new (all_opts=3D0x807e7cf0, block_default= _type=3D) at /home/cborntra/REPOS/qemu/blockdev.c:930 > #11 0x00000000800d11d4 in drive_init_func (opts=3D, opaque= =3D) at /home/cborntra/REPOS/qemu/vl.c:1144 > #12 0x00000000802110b0 in qemu_opts_foreach (list=3D, func= =3Dfunc@entry=3D0x800d11a8 , opaque=3Dopaque@entry=3D0x807= de6c0, abort_on_failure=3Dabort_on_failure@entry=3D1) > at /home/cborntra/REPOS/qemu/util/qemu-option.c:1072 > #13 0x0000000080016438 in main (argc=3D, argv=3D, envp=3D) at /home/cborntra/REPOS/qemu/vl.c:4352 > --> No idea Ah, I forgot about this one. This is the Linux AIO completion eventfd. It gets signalled when a Linux AIO request completes and we need to call io_getevents(2). You can avoid it by using aio=3Dthreads instead of aio=3Dnative. But then you cannot use Linux AIO. I am not aware of a good way around using this fd. > Breakpoint 1, event_notifier_init (e=3De@entry=3D0x807f4eb0, active=3Dact= ive@entry=3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #0 event_notifier_init (e=3De@entry=3D0x807f4eb0, active=3Dactive@entry= =3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #1 0x000000008019f04c in thread_pool_init_one (ctx=3D0x807e8e00, pool=3D= 0x807f4eb0) at /home/cborntra/REPOS/qemu/thread-pool.c:296 > #2 thread_pool_new (ctx=3D) at /home/cborntra/REPOS/qemu/= thread-pool.c:314 > #3 0x000000008019e590 in aio_get_thread_pool (ctx=3D0x807e8e00) at /home= /cborntra/REPOS/qemu/async.c:245 > #4 0x00000000801e8f6c in paio_submit (bs=3Dbs@entry=3D0x807fd1a0, fd=3D<= optimized out>, sector_num=3Dsector_num@entry=3D0, qiov=3Dqiov@entry=3D0x3f= fffffda98, nb_sectors=3Dnb_sectors@entry=3D1, cb=3D > 0x801a1a4c , opaque=3D0x3ffba3fe8d0, type=3D4= 097) at /home/cborntra/REPOS/qemu/block/raw-posix.c:1027 > #5 0x00000000801e9b5c in raw_aio_submit (bs=3D0x807fd1a0, sector_num=3D0= , qiov=3D0x3ffffffda98, nb_sectors=3D, cb=3Dcb@entry=3D0x801= a1a4c , opaque=3D0x3ffba3fe8d0, type=3D4097) > at /home/cborntra/REPOS/qemu/block/raw-posix.c:1056 > #6 0x00000000801e9c84 in raw_aio_readv (bs=3D, sector_num= =3D, qiov=3D, nb_sectors=3D, c= b=3D0x801a1a4c , opaque=3D0x3ffba3fe8d0) > at /home/cborntra/REPOS/qemu/block/raw-posix.c:1094 > #7 0x00000000801a2594 in bdrv_co_io_em (is_write=3Dfalse, iov=3D0x3fffff= fda98, nb_sectors=3D, sector_num=3D0, bs=3D0x807fd1a0) at /h= ome/cborntra/REPOS/qemu/block.c:4835 > #8 bdrv_co_readv_em (bs=3Dbs@entry=3D0x807fd1a0, sector_num=3Dsector_num= @entry=3D0, nb_sectors=3D, iov=3Diov@entry=3D0x3ffffffda98) = at /home/cborntra/REPOS/qemu/block.c:4852 > #9 0x00000000801a7d7c in bdrv_aligned_preadv (bs=3Dbs@entry=3D0x807fd1a0= , req=3Dreq@entry=3D0x3ffba3feac8, offset=3D, bytes=3Dbytes@= entry=3D512, align=3D, qiov=3D0x3ffffffda98, flags=3D0) > at /home/cborntra/REPOS/qemu/block.c:3057 > #10 0x00000000801a82da in bdrv_co_do_preadv (bs=3D0x807fd1a0, offset=3D, bytes=3D512, qiov=3D0x3ffffffda98, flags=3D, = flags@entry=3D(unknown: 0)) > at /home/cborntra/REPOS/qemu/block.c:3136 > #11 0x00000000801a83e4 in bdrv_co_do_readv (flags=3D(unknown: 0), qiov=3D= , nb_sectors=3D, sector_num=3D= , bs=3D) > at /home/cborntra/REPOS/qemu/block.c:3158 > #12 bdrv_co_readv (bs=3D, sector_num=3D, nb= _sectors=3D, qiov=3D) at /home/cborntra/REPOS= /qemu/block.c:3167 > #13 0x00000000801a7ce2 in bdrv_aligned_preadv (bs=3Dbs@entry=3D0x807fa620= , req=3Dreq@entry=3D0x3ffba3fedb0, offset=3D, bytes=3Dbytes@= entry=3D512, align=3D512, qiov=3D0x3ffffffda98, flags=3D0) > at /home/cborntra/REPOS/qemu/block.c:3042 > #14 0x00000000801a82da in bdrv_co_do_preadv (bs=3D0x807fa620, offset=3D, bytes=3D512, qiov=3D0x3ffffffda98, flags=3D) = at /home/cborntra/REPOS/qemu/block.c:3136 > #15 0x00000000801a94d8 in bdrv_rw_co_entry (opaque=3D0x3ffffffd9b8) at /h= ome/cborntra/REPOS/qemu/block.c:2693 > #16 bdrv_rw_co_entry (opaque=3D0x3ffffffd9b8) at /home/cborntra/REPOS/qem= u/block.c:2688 > #17 0x00000000801ba140 in coroutine_trampoline (i0=3D, i1= =3D) at /home/cborntr= a/REPOS/qemu/coroutine-ucontext.c:118 > #18 0x000003fffc935892 in __makecontext_ret () from /lib64/libc.so.6 > --> No idea Similar deal to the Linux AIO event notifier. It's the fd used to signal thread pool work item completion. The threadpool is per-AioContext so the fd overhead is per-iothread. However, we can use a BH instead since the API has now been made thread-safe. Previously we used EventNotifier because qemu_bh_schedule() was not thread-safe. I will send a patch but I'm not sure it's critical enough for QEMU 2.1. Do you have a bug report or justification for pushing this into QEMU 2.1? > Breakpoint 1, event_notifier_init (e=3De@entry=3D0x808b8054, active=3Dact= ive@entry=3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #0 event_notifier_init (e=3De@entry=3D0x808b8054, active=3Dactive@entry= =3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #1 0x000000008019e766 in aio_context_new () at /home/cborntra/REPOS/qemu= /async.c:274 > #2 0x00000000800be410 in iothread_complete (obj=3D, errp= =3D) at /home/cborntra/REPOS/qemu/iothread.c:69 > #3 0x000000008006d3bc in virtio_blk_data_plane_create (vdev=3Dvdev@entry= =3D0x807f29e0, blk=3Dblk@entry=3D0x807f2ad0, dataplane=3Ddataplane@entry=3D= 0x807f2b48, errp=3Derrp@entry=3D0x3ffffffe0e8) > at /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:172 > #4 0x000000008006ba22 in virtio_blk_device_realize (dev=3D0x807f29e0, er= rp=3D0x3ffffffe198) at /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c:751 > #5 0x0000000080077ee2 in virtio_device_realize (dev=3D0x807f29e0, errp= =3D0x3ffffffe250) at /home/cborntra/REPOS/qemu/hw/virtio/virtio.c:1294 > #6 0x0000000080131760 in device_set_realized (obj=3D0x807f29e0, value=3D= , errp=3D0x3ffffffe5b0) at /home/cborntra/REPOS/qemu/hw/core= /qdev.c:834 > #7 0x0000000080162dca in property_set_bool (obj=3Dobj@entry=3D0x807f29e0= , v=3Dv@entry=3D0x808a3a90, opaque=3D0x807f31f0, name=3Dname@entry=3D0x8025= bdd2 "realized", errp=3Derrp@entry=3D0x3ffffffe5b0) > at /home/cborntra/REPOS/qemu/qom/object.c:1473 > #8 0x0000000080164bd6 in object_property_set (obj=3Dobj@entry=3D0x807f29= e0, v=3D0x808a3a90, name=3Dname@entry=3D0x8025bdd2 "realized", errp=3Derrp@= entry=3D0x3ffffffe5b0) at /home/cborntra/REPOS/qemu/qom/object.c:824 > #9 0x0000000080166a3a in object_property_set_qobject (obj=3D0x807f29e0, = value=3D, name=3D0x8025bdd2 "realized", errp=3D0x3ffffffe5b0= ) at /home/cborntra/REPOS/qemu/qom/qom-qobject.c:24 > #10 0x0000000080164efc in object_property_set_bool (obj=3Dobj@entry=3D0x8= 07f29e0, value=3Dvalue@entry=3Dtrue, name=3Dname@entry=3D0x8025bdd2 "realiz= ed", errp=3Derrp@entry=3D0x3ffffffe5b0) > at /home/cborntra/REPOS/qemu/qom/object.c:888 > #11 0x0000000080130312 in qdev_init (dev=3Ddev@entry=3D0x807f29e0) at /ho= me/cborntra/REPOS/qemu/hw/core/qdev.c:168 > #12 0x00000000800893bc in virtio_ccw_blk_init (ccw_dev=3D0x807f2780) at /= home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:804 > #13 0x000000008008a6d4 in virtio_ccw_busdev_init (dev=3D0x807f2780) at /h= ome/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:1582 > #14 0x000000008012fb2a in device_realize (dev=3D0x807f2780, errp=3D0x3fff= fffe870) at /home/cborntra/REPOS/qemu/hw/core/qdev.c:183 > #15 0x0000000080131760 in device_set_realized (obj=3D0x807f2780, value=3D= , errp=3D0x3ffffffebe8) at /home/cborntra/REPOS/qemu/hw/core= /qdev.c:834 > #16 0x0000000080162dca in property_set_bool (obj=3Dobj@entry=3D0x807f2780= , v=3Dv@entry=3D0x8089d9c0, opaque=3D0x807f2bd0, name=3Dname@entry=3D0x8025= bdd2 "realized", errp=3Derrp@entry=3D0x3ffffffebe8) > at /home/cborntra/REPOS/qemu/qom/object.c:1473 > #17 0x0000000080164bd6 in object_property_set (obj=3Dobj@entry=3D0x807f27= 80, v=3D0x8089d9c0, name=3Dname@entry=3D0x8025bdd2 "realized", errp=3Derrp@= entry=3D0x3ffffffebe8) at /home/cborntra/REPOS/qemu/qom/object.c:824 > #18 0x0000000080166a3a in object_property_set_qobject (obj=3D0x807f2780, = value=3D, name=3D0x8025bdd2 "realized", errp=3D0x3ffffffebe8= ) at /home/cborntra/REPOS/qemu/qom/qom-qobject.c:24 > #19 0x0000000080164efc in object_property_set_bool (obj=3Dobj@entry=3D0x8= 07f2780, value=3Dvalue@entry=3Dtrue, name=3Dname@entry=3D0x8025bdd2 "realiz= ed", errp=3Derrp@entry=3D0x3ffffffebe8) > at /home/cborntra/REPOS/qemu/qom/object.c:888 > #20 0x00000000800bf622 in qdev_device_add (opts=3D0x807e8080) at /home/cb= orntra/REPOS/qemu/qdev-monitor.c:560 > #21 0x00000000800d1616 in device_init_func (opts=3D, opaqu= e=3D) at /home/cborntra/REPOS/qemu/vl.c:2357 > #22 0x00000000802110b0 in qemu_opts_foreach (list=3D, func= =3Dfunc@entry=3D0x800d15f0 , opaque=3Dopaque@entry=3D0x0,= abort_on_failure=3Dabort_on_failure@entry=3D1) > at /home/cborntra/REPOS/qemu/util/qemu-option.c:1072 > #23 0x000000008001673a in main (argc=3D, argv=3D, envp=3D) at /home/cborntra/REPOS/qemu/vl.c:4431 >=20 > --> data plane create, eventfd for iothread. I guess we need one per ioth= read? Yes, this is the per-iothread aio_notify() event notifier. > System now boots, and then the first disk access (partition detection): >=20 > Breakpoint 1, event_notifier_init (e=3De@entry=3D0x808b6848, active=3Dact= ive@entry=3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #0 event_notifier_init (e=3De@entry=3D0x808b6848, active=3Dactive@entry= =3D0) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #1 0x000000008008839a in virtio_ccw_set_guest_notifier (dev=3Ddev@entry= =3D0x807f2780, n=3Dn@entry=3D0, assign=3Dassign@entry=3Dtrue, with_irqfd=3D= with_irqfd@entry=3Dtrue) > at /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:1201 > #2 0x000000008008a7bc in virtio_ccw_set_guest_notifiers (d=3D, nvqs=3D, assigned=3D) at /home/cborntra= /REPOS/qemu/hw/s390x/virtio-ccw.c:1259 > #3 0x000000008006d4fa in virtio_blk_data_plane_start (s=3D0x808b7e10) at= /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:222 > #4 0x000000008006cf10 in virtio_blk_handle_output (vdev=3D, vq=3D) at /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c= :427 > #5 0x0000000080086da0 in virtio_ccw_hcall_notify (args=3D= ) at /home/cborntra/REPOS/qemu/hw/s390x/s390-virtio-ccw.c:60 > #6 0x0000000080082084 in s390_virtio_hypercall (env=3Denv@entry=3D0x8088= 5398) at /home/cborntra/REPOS/qemu/hw/s390x/s390-virtio-hcall.c:34 > #7 0x00000000800b83a4 in handle_hypercall (run=3D, cpu=3D= 0x8087d100) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:911 > #8 handle_diag (ipb=3D, run=3D, cpu=3D0x80= 87d100) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:963 > #9 handle_instruction (run=3D, cpu=3D0x8087d100) at /home= /cborntra/REPOS/qemu/target-s390x/kvm.c:1091 > #10 handle_intercept (cpu=3D0x8087d100) at /home/cborntra/REPOS/qemu/targ= et-s390x/kvm.c:1141 > #11 kvm_arch_handle_exit (cs=3Dcs@entry=3D0x8087d100, run=3Drun@entry=3D0= x3fffdfcf000) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:1259 > #12 0x000000008005b4d6 in kvm_cpu_exec (cpu=3Dcpu@entry=3D0x8087d100) at = /home/cborntra/REPOS/qemu/kvm-all.c:1792 > #13 0x000000008004733e in qemu_kvm_cpu_thread_fn (arg=3D0x8087d100) at /h= ome/cborntra/REPOS/qemu/cpus.c:874 > #14 0x000003fffdd6b412 in start_thread () from /lib64/libpthread.so.0 > #15 0x000003fffc9f10ae in thread_start () from /lib64/libc.so.6 > ---> irqfd, ok Yes. > Breakpoint 1, event_notifier_init (e=3De@entry=3D0x808b6850, active=3Dact= ive@entry=3D1) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #0 event_notifier_init (e=3De@entry=3D0x808b6850, active=3Dactive@entry= =3D1) at /home/cborntra/REPOS/qemu/util/event_notifier-posix.c:29 > #1 0x000000008008785a in virtio_ccw_set_guest2host_notifier (dev=3D, n=3D, assign=3D, set_handler=3D) > at /home/cborntra/REPOS/qemu/hw/s390x/virtio-ccw.c:141 > #2 0x000000008006d526 in virtio_blk_data_plane_start (s=3D0x808b7e10) at= /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:230 > #3 0x000000008006cf10 in virtio_blk_handle_output (vdev=3D, vq=3D) at /home/cborntra/REPOS/qemu/hw/block/virtio-blk.c= :427 > #4 0x0000000080086da0 in virtio_ccw_hcall_notify (args=3D= ) at /home/cborntra/REPOS/qemu/hw/s390x/s390-virtio-ccw.c:60 > #5 0x0000000080082084 in s390_virtio_hypercall (env=3Denv@entry=3D0x8088= 5398) at /home/cborntra/REPOS/qemu/hw/s390x/s390-virtio-hcall.c:34 > #6 0x00000000800b83a4 in handle_hypercall (run=3D, cpu=3D= 0x8087d100) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:911 > #7 handle_diag (ipb=3D, run=3D, cpu=3D0x80= 87d100) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:963 > #8 handle_instruction (run=3D, cpu=3D0x8087d100) at /home= /cborntra/REPOS/qemu/target-s390x/kvm.c:1091 > #9 handle_intercept (cpu=3D0x8087d100) at /home/cborntra/REPOS/qemu/targ= et-s390x/kvm.c:1141 > #10 kvm_arch_handle_exit (cs=3Dcs@entry=3D0x8087d100, run=3Drun@entry=3D0= x3fffdfcf000) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:1259 > #11 0x000000008005b4d6 in kvm_cpu_exec (cpu=3Dcpu@entry=3D0x8087d100) at = /home/cborntra/REPOS/qemu/kvm-all.c:1792 > #12 0x000000008004733e in qemu_kvm_cpu_thread_fn (arg=3D0x8087d100) at /h= ome/cborntra/REPOS/qemu/cpus.c:874 > #13 0x000003fffdd6b412 in start_thread () from /lib64/libpthread.so.0 > #14 0x000003fffc9f10ae in thread_start () from /lib64/libc.so.6 > ---> ioeventfd, ok Yes. Stefan --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTv60WAAoJEJykq7OBq3PIY0QIALHPD6dTuyjUzvKMmc7MnrhY F1SJx00dW2D1GIWwCKJe+FNE1DEA2IxN0leETKNDBNmhxKdwhAJaDjJ5gCvkaHex zAgH4PFRMiQJJa0P7D4Yse/b3HYvGLTkyvZiu9MqE0/Aa80nDbcuWTjbQO2ZLq0o U3ECIBCoZIOcqvuHrtzv8sCeweYLaFhuSmZeJ9CeKccdVAImnZ8lOB3EPIEum1Wa gm3/8dqH0w6jVl4T7Hx/Rsv+I7GVHIKsfO4Hb07paf+EH4DSE8QxmF63AwdpAWt7 Q3zxVEtcDW8sleh+0yPEDGjpwc/OHKZ+/tzvIkt262qLAbggvslYPeTTgpzYXmc= =ygye -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j--