Re: [Qemu-arm] Regression on KVM qemu-system-aarch64 since "monitor: enable IO thread for (qmp & !mux) typed"

[Auger Eric]

Hi,

On 23/03/18 13:11, Peter Maydell wrote:
> On 23 March 2018 at 12:01, Auger Eric <address@hidden> wrote:
>> Hi,
>>
>> On 23/03/18 11:26, Peter Maydell wrote:
>>> On 23 March 2018 at 10:24, Auger Eric <address@hidden> 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
>