On Sat, 17 Feb 2018 10:07:38 +0100
Jan Kiszka <jan.kis...@web.de> wrote:


> > Seems like no one is doing guest debugging with kvm on x86 except
> > me, and I'm only doing it too infrequently now: This one broke that
> > use case for SMP guests long ago. How was it tested?
> > 
> > To reproduce the bug: set up an x86-64 guest kernel with > 1 core,
> > break on some prominent syscall entry (e.g. sys_execve), continue
> > the guest on hit and it will quickly lock up, even after disabling
> > the breakpoint again. Kernel version doesn't matter (was my first
> > guess), gdb is (OpenSUSE) here.


> Sending packet: $Hg1#e0...Ack
> Packet received: OK
> Sending packet: $mffffc90000c0bf30,8#83...Ack
> Packet received: ae180081ffffffff
> Sending packet: $mffffc90000c0bf30,8#83...Ack
> Packet received: ae180081ffffffff
> Breakpoint 1, SyS_execve (filename=7029648, argv=7583376,
> envp=7598304) at ../fs/exec.c:1923 (gdb) c
> Continuing.
> Sending packet: $vCont;s:1#23...Ack
> ...and now the guest is dead. I can still interrupt it, but it's
> otherwise not working properly.

I tried, but I could not reproduce this bug neither on s390x nor on
amd64. in both cases I used recent enough versions of qemu so that
they have the patch you mentioned, and qemu was started with several
cpus (I tried 64 on s390x, and 4 on amd64).

in particular on amd64:
host: 4.4.0-112-generic (ubuntu 16.04)
QEMU version 2.10.0  (vanilla from git)
gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1

I also used the gdb script you provided but everything worked both with
-smp 1 and with -smp 4

the only issue I had was that I had to disable kaslr in the guest to be
able to do anything, but that does not seem to be the problem you have.

my primary suspicion at this point would be an issue in KVM, and not
in qemu. have you tried running it without KVM? what is the version of
qemu and kernel in the host?


Reply via email to