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

[Peter Xu]

On Fri, Mar 23, 2018 at 01:36:36PM +0100, Auger Eric wrote:
> 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

I'm not sure, but I suspect libvirt has already sent something to QEMU
before this point, which breaks the timing of the old QMP code (the
old QMP won't do anything until main loop).

I'm thinking maybe I should postpone the monitors at least until main
loop so that we can still keep that assumption.  But I'll see what do
others think of it first.

Thanks,

-- 
Peter Xu