qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] Regression on KVM qemu-system-aarch64 since "monitor: ena


From: Peter Xu
Subject: Re: [Qemu-arm] Regression on KVM qemu-system-aarch64 since "monitor: enable IO thread for (qmp & !mux) typed"
Date: Wed, 28 Mar 2018 15:21:55 +0800
User-agent: Mutt/1.9.1 (2017-09-22)

On Wed, Mar 28, 2018 at 08:49:59AM +0200, Auger Eric wrote:
> Hi Peter,
> 
> On 28/03/18 04:03, Peter Xu wrote:
> > 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.
> 
> Yes it works for me with the reverts.
> 
>  But does ARM use postcopy, and will ARM need the
> > coming network failure recovery feature?
> 
> I assume it does
> > 
> > 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).
> 
> OK. I need to have a look at your series to better understand what it does.

It introduced a dedicated iothread to run IO part of the monitor code
(e.g., parsing of QMP input, and reply of the responses).  So now the
parsing could start earlier, before the main loop (that's what I
suspect the problem before), and meanwhile QMP IOs can happen in
parallel now with main thread, which it never can before (since all
QMP logic will be in main thread).

I would be curious about what commands have been sent by libvirt to
QEMU-arm when reach this point.  Please feel free to let me know if I
can help in any form.  For example, if there is an ARM server that I
can login and run both libvirt and QEMU, I'd be glad to play with it
too.

Thanks,

-- 
Peter Xu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]