qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Regression on KVM qemu-system-aarch64 since "monitor: e


From: Peter Maydell
Subject: Re: [Qemu-devel] Regression on KVM qemu-system-aarch64 since "monitor: enable IO thread for (qmp & !mux) typed"
Date: Fri, 23 Mar 2018 12:11:17 +0000

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 (;;) { }
   }

and then QEMU will sit in a loop waiting for you to do a
  gdb path/to/qemu <pid>

thanks
-- PMM



reply via email to

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