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 think current master should work fine with ARM KVM now since OOB is
now off by default. But does ARM use postcopy, and will ARM need the
coming network failure recovery feature?

If so, maybe we'll still need to have a look on this single problem
(this is the only non-testcase issue I know now with Out-Of-Band).

Thanks,

-- 
Peter Xu