Hi, On 23/03/18 13:11, Peter Maydell wrote: > On 23 March 2018 at 12:01, Auger Eric <eric.au...@redhat.com> wrote: >> Hi, >> >> On 23/03/18 11:26, Peter Maydell wrote: >>> On 23 March 2018 at 10:24, Auger Eric <eric.au...@redhat.com> wrote: >>>> Hi, >>>> >>>> I observe a regression on KVM accelerated qemu-system-aarch64: >>>> >>>> Unexpected error in kvm_device_access() at >>>> /home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164: >>>> 2018-03-23T09:59:59.629439Z qemu-system-aarch64: KVM_GET_DEVICE_ATTR >>>> failed: Group 6 attr 0x000000000000c664: Device or resource busy >>>> 2018-03-23 10:00:00.085+0000: shutting down, reason=crashed >>> >>> Can you get a backtrace for this? (I guess you'd need to fiddle >>> with the kvm_device_access() code to make it assert rather >>> than passing back the error). >> >> OK. I will try to do so. As I could have expected, I cannot reproduce on >> a standalone qemu command line. The problem observed above is seen with >> libvirt launch which may be doing some other QMP stuff concurrently? > > Hmm, that could be a bit painful to debug. I dunno if libvirt > has a "launch QEMU under gdb" option. If not, you could try > something like: > if (condition we want to get a backtrace on) { > printf("hit condition, attach gdb to process %d\n", (int)getpid()); > for (;;) { } > }
Thanks for the hint. Here is the stack I get. #0 kvm_device_access (fd=31, group=6, attr=50788, val=0x5937c88, write=false, errp=0x16984a8 <error_abort>) at /home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164 #1 0x00000000004f8ce4 in arm_gicv3_icc_reset (env=0xffffa1fc8330, ri=0x597f910) at /home/augere/UPSTREAM/qemu/hw/intc/arm_gicv3_kvm.c:632 #2 0x00000000006351ac in cp_reg_reset (key=0x597f730, value=0x597f910, opaque=0xffffa1fc0010) at /home/augere/UPSTREAM/qemu/target/arm/cpu.c:78 #3 0x0000ffffa47edce4 in g_hash_table_foreach () from /lib64/libglib-2.0.so.0 #4 0x0000000000635394 in arm_cpu_reset (s=0xffffa1fc0010) at /home/augere/UPSTREAM/qemu/target/arm/cpu.c:130 #5 0x000000000090c888 in cpu_reset (cpu=0xffffa1fc0010) at qom/cpu.c:249 #6 0x00000000005793d8 in do_cpu_reset (opaque=0xffffa1fc0010) at /home/augere/UPSTREAM/qemu/hw/arm/boot.c:665 #7 0x000000000073095c in qemu_devices_reset () at hw/core/reset.c:69 #8 0x00000000006976e0 in qemu_system_reset (reason=SHUTDOWN_CAUSE_NONE) at vl.c:1731 #9 0x000000000069fd60 in main (argc=69, argv=0xffffe877d1a8, envp=0xffffe877d3d8) at vl.c:4697 Thanks Eric > > and then QEMU will sit in a loop waiting for you to do a > gdb path/to/qemu <pid> > > thanks > -- PMM >