semantic: 0.947
permissions: 0.942
mistranslation: 0.935
arm: 0.926
performance: 0.921
architecture: 0.918
debug: 0.916
graphic: 0.914
user-level: 0.910
assembly: 0.907
register: 0.903
risc-v: 0.901
TCG: 0.900
device: 0.900
virtual: 0.892
PID: 0.889
peripherals: 0.865
kernel: 0.861
VMM: 0.859
ppc: 0.851
network: 0.846
socket: 0.837
boot: 0.837
hypervisor: 0.832
KVM: 0.831
vnc: 0.809
x86: 0.803
files: 0.758
i386: 0.728

Undefined behaviour when running guest with -enable-kvm and attached debugger
Description of problem:
When attaching a debugger to a Qemu instance with `-enable-kvm` my linux kernel panics on (f.e.) module load.
I am not sure if this is a Qemu bug, however the issue is not occurring if I a) do not attach the debugger (even though Qemu is listening for one) or b) I do not pass `-enable-kvm` (and attach a debugger).
The issue seems to relate to the `lx-symbols` command provided by the Linux kernel gdb script suite.
Every time a module is loaded this script will reload the symbols for said module which may take some time, so maybe there is some race involved?
The issue does not reproduce if you do not run `lx-symbols` prior to continuing (it will however run automatically after first module load as it adds a breakpoint to kernel/module/main.c:do_init_module, so the kernel will crash after the second module load)
Steps to reproduce:
1. Start kernel with some img
2. Attach gdb debugger
3. Run the `lx-symbols` command provided by the Linux kernel gdb scripts in gdb, run `continue` in gdb
3. Load a kernel module
Additional information:
This is the kernel stack trace:
```
[   22.930691] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[   22.931174] CPU: 2 PID: 241 Comm: modprobe Tainted: G            E      6.1.31+ #2
[   22.931675] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
[   22.931675] RIP: 0010:do_init_module+0x1/0x210
[   22.931675] Code: 74 0c 48 8b 78 08 48 89 de e8 8b df ff ff 65 ff 0d 84 94 ef 7e 0f 85 e5 fe ff ff 0f 1f 44 00 008
[   22.931675] RSP: 0018:ffffc90000593e40 EFLAGS: 00010246
[   22.931675] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000006e202
[   22.931675] RDX: 000000000006e002 RSI: 5b4504de76578f76 RDI: ffffffffc024e180
[   22.931675] RBP: ffffc90000593e50 R08: ffffea0000174a88 R09: ffffea0000174ac0
[   22.931675] R10: ffff888006a9c270 R11: 0000000000000100 R12: 0000562f9087b4a0
[   22.931675] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[   22.931675] FS:  00007f0dbc5a4040(0000) GS:ffff88801f500000(0000) knlGS:0000000000000000
[   22.931675] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   22.931675] CR2: 00007ffdc94bc3f8 CR3: 0000000006f8e000 CR4: 00000000003506e0
[   22.931675] Call Trace:
[   22.931675]  <TASK>
[   22.931675]  ? die+0x32/0x80
[   22.931675]  ? do_trap+0xd6/0x100
[   22.931675]  ? do_init_module+0x1/0x210
[   22.931675]  ? do_error_trap+0x6a/0x90
[   22.931675]  ? do_init_module+0x1/0x210
[   22.931675]  ? exc_invalid_op+0x4c/0x60
[   22.931675]  ? do_init_module+0x1/0x210
[   22.931675]  ? asm_exc_invalid_op+0x16/0x20
[   22.931675]  ? do_init_module+0x1/0x210
[   22.931675]  __do_sys_finit_module+0x9e/0xf0
[   22.931675]  do_syscall_64+0x63/0x90
[   22.931675]  ? exit_to_user_mode_prepare+0x1a/0x120
[   22.931675]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
```