13 files changed, 882 insertions, 0 deletions
diff --git a/results/classifier/108/other/56 b/results/classifier/108/other/56
new file mode 100644
index 000000000..c2b065afc
--- /dev/null
+++ b/results/classifier/108/other/56
@@ -0,0 +1,16 @@
+device: 0.784
+boot: 0.429
+graphic: 0.386
+debug: 0.359
+performance: 0.239
+vnc: 0.194
+other: 0.192
+semantic: 0.153
+PID: 0.145
+files: 0.026
+permissions: 0.020
+socket: 0.003
+KVM: 0.002
+network: 0.001
+
+Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused]
diff --git a/results/classifier/108/other/560 b/results/classifier/108/other/560
new file mode 100644
index 000000000..2f6a19b80
--- /dev/null
+++ b/results/classifier/108/other/560
@@ -0,0 +1,16 @@
+device: 0.817
+performance: 0.658
+semantic: 0.500
+network: 0.393
+other: 0.278
+graphic: 0.262
+boot: 0.210
+PID: 0.202
+files: 0.129
+debug: 0.097
+vnc: 0.057
+permissions: 0.048
+socket: 0.021
+KVM: 0.003
+
+User-emu documentation mentions inexistent "runtime" downloads
diff --git a/results/classifier/108/other/561 b/results/classifier/108/other/561
new file mode 100644
index 000000000..05ac381fc
--- /dev/null
+++ b/results/classifier/108/other/561
@@ -0,0 +1,16 @@
+device: 0.855
+graphic: 0.454
+debug: 0.402
+boot: 0.302
+network: 0.230
+semantic: 0.214
+vnc: 0.188
+performance: 0.096
+socket: 0.094
+permissions: 0.033
+KVM: 0.025
+other: 0.025
+PID: 0.024
+files: 0.021
+
+Q35 - ACPI PCI hot-plug issue with Windows guest
diff --git a/results/classifier/108/other/562107 b/results/classifier/108/other/562107
new file mode 100644
index 000000000..ac246c973
--- /dev/null
+++ b/results/classifier/108/other/562107
@@ -0,0 +1,45 @@
+device: 0.733
+semantic: 0.721
+socket: 0.679
+network: 0.675
+other: 0.588
+debug: 0.550
+performance: 0.546
+graphic: 0.526
+files: 0.478
+PID: 0.474
+vnc: 0.400
+boot: 0.356
+permissions: 0.344
+KVM: 0.175
+
+QEmu GDB stub uses IPv6 instead of v4 (or both)
+
+This bug has been reported by several people already.
+
+See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/
+and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248
+
+
+Seems like a very easy fix. 
+
+Regards,
+Matthijs ter Woord
+
+There is an alternative way to force gdbserver to use ipv4 instead ipv6 without changing the source code. 
+
+Use this command:
+
+c:\>qemu -S -gdb tcp::1234,ipv4 <...other parameters>
+
+Works for me until there is a bugfix for this.
+
+Thanks.
+
+I have a patch for this...
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/56309929 b/results/classifier/108/other/56309929
new file mode 100644
index 000000000..54419195f
--- /dev/null
+++ b/results/classifier/108/other/56309929
@@ -0,0 +1,190 @@
+other: 0.690
+device: 0.646
+KVM: 0.636
+performance: 0.608
+vnc: 0.600
+network: 0.589
+permissions: 0.587
+debug: 0.585
+boot: 0.578
+graphic: 0.570
+PID: 0.561
+semantic: 0.521
+socket: 0.516
+files: 0.311
+
+[Qemu-devel] [BUG 2.6] Broken CONFIG_TPM?
+
+A compilation test with clang -Weverything reported this problem:
+
+config-host.h:112:20: warning: '$' in identifier
+[-Wdollar-in-identifier-extension]
+
+The line of code looks like this:
+
+#define CONFIG_TPM $(CONFIG_SOFTMMU)
+
+This is fine for Makefile code, but won't work as expected in C code.
+
+Am 28.04.2016 um 22:33 schrieb Stefan Weil:
+>
+A compilation test with clang -Weverything reported this problem:
+>
+>
+config-host.h:112:20: warning: '$' in identifier
+>
+[-Wdollar-in-identifier-extension]
+>
+>
+The line of code looks like this:
+>
+>
+#define CONFIG_TPM $(CONFIG_SOFTMMU)
+>
+>
+This is fine for Makefile code, but won't work as expected in C code.
+>
+A complete 64 bit build with clang -Weverything creates a log file of
+1.7 GB.
+Here are the uniq warnings sorted by their frequency:
+
+      1 -Wflexible-array-extensions
+      1 -Wgnu-folding-constant
+      1 -Wunknown-pragmas
+      1 -Wunknown-warning-option
+      1 -Wunreachable-code-loop-increment
+      2 -Warray-bounds-pointer-arithmetic
+      2 -Wdollar-in-identifier-extension
+      3 -Woverlength-strings
+      3 -Wweak-vtables
+      4 -Wgnu-empty-struct
+      4 -Wstring-conversion
+      6 -Wclass-varargs
+      7 -Wc99-extensions
+      7 -Wc++-compat
+      8 -Wfloat-equal
+     11 -Wformat-nonliteral
+     16 -Wshift-negative-value
+     19 -Wglobal-constructors
+     28 -Wc++11-long-long
+     29 -Wembedded-directive
+     38 -Wvla
+     40 -Wcovered-switch-default
+     40 -Wmissing-variable-declarations
+     49 -Wold-style-cast
+     53 -Wgnu-conditional-omitted-operand
+     56 -Wformat-pedantic
+     61 -Wvariadic-macros
+     77 -Wc++11-extensions
+     83 -Wgnu-flexible-array-initializer
+     83 -Wzero-length-array
+     96 -Wgnu-designator
+    102 -Wmissing-noreturn
+    103 -Wconditional-uninitialized
+    107 -Wdisabled-macro-expansion
+    115 -Wunreachable-code-return
+    134 -Wunreachable-code
+    243 -Wunreachable-code-break
+    257 -Wfloat-conversion
+    280 -Wswitch-enum
+    291 -Wpointer-arith
+    298 -Wshadow
+    378 -Wassign-enum
+    395 -Wused-but-marked-unused
+    420 -Wreserved-id-macro
+    493 -Wdocumentation
+    510 -Wshift-sign-overflow
+    565 -Wgnu-case-range
+    566 -Wgnu-zero-variadic-macro-arguments
+    650 -Wbad-function-cast
+    705 -Wmissing-field-initializers
+    817 -Wgnu-statement-expression
+    968 -Wdocumentation-unknown-command
+   1021 -Wextra-semi
+   1112 -Wgnu-empty-initializer
+   1138 -Wcast-qual
+   1509 -Wcast-align
+   1766 -Wextended-offsetof
+   1937 -Wsign-compare
+   2130 -Wpacked
+   2404 -Wunused-macros
+   3081 -Wpadded
+   4182 -Wconversion
+   5430 -Wlanguage-extension-token
+   6655 -Wshorten-64-to-32
+   6995 -Wpedantic
+   7354 -Wunused-parameter
+  27659 -Wsign-conversion
+
+Stefan Weil <address@hidden> writes:
+
+>
+A compilation test with clang -Weverything reported this problem:
+>
+>
+config-host.h:112:20: warning: '$' in identifier
+>
+[-Wdollar-in-identifier-extension]
+>
+>
+The line of code looks like this:
+>
+>
+#define CONFIG_TPM $(CONFIG_SOFTMMU)
+>
+>
+This is fine for Makefile code, but won't work as expected in C code.
+Broken in commit 3b8acc1 "configure: fix TPM logic".  Cc'ing Paolo.
+
+Impact: #ifdef CONFIG_TPM never disables code.  There are no other uses
+of CONFIG_TPM in C code.
+
+I had a quick peek at configure and create_config, but refrained from
+attempting to fix this, since I don't understand when exactly CONFIG_TPM
+should be defined.
+
+On 29 April 2016 at 08:42, Markus Armbruster <address@hidden> wrote:
+>
+Stefan Weil <address@hidden> writes:
+>
+>
+> A compilation test with clang -Weverything reported this problem:
+>
+>
+>
+> config-host.h:112:20: warning: '$' in identifier
+>
+> [-Wdollar-in-identifier-extension]
+>
+>
+>
+> The line of code looks like this:
+>
+>
+>
+> #define CONFIG_TPM $(CONFIG_SOFTMMU)
+>
+>
+>
+> This is fine for Makefile code, but won't work as expected in C code.
+>
+>
+Broken in commit 3b8acc1 "configure: fix TPM logic".  Cc'ing Paolo.
+>
+>
+Impact: #ifdef CONFIG_TPM never disables code.  There are no other uses
+>
+of CONFIG_TPM in C code.
+>
+>
+I had a quick peek at configure and create_config, but refrained from
+>
+attempting to fix this, since I don't understand when exactly CONFIG_TPM
+>
+should be defined.
+Looking at 'git blame' suggests this has been wrong like this for
+some years, so we don't need to scramble to fix it for 2.6.
+
+thanks
+-- PMM
+
diff --git a/results/classifier/108/other/564 b/results/classifier/108/other/564
new file mode 100644
index 000000000..2c6afeb99
--- /dev/null
+++ b/results/classifier/108/other/564
@@ -0,0 +1,28 @@
+graphic: 0.870
+device: 0.818
+boot: 0.697
+files: 0.686
+permissions: 0.550
+PID: 0.518
+performance: 0.490
+socket: 0.442
+semantic: 0.440
+network: 0.376
+debug: 0.178
+vnc: 0.172
+other: 0.124
+KVM: 0.036
+
+Enable opengl virtio-gpu virgl vulkan in windows build
+Additional information:
+```
+PS E:\scoopg\apps\qemu\current> ./qemu-system-x86_64.exe -drive file=E:\groot_02\vdisks\gparted-live.iso,if=virtio  -boot c -m 4096 -machine type=pc,accel=whpx,kernel-irqchip=off -smp 8,sockets=1,cores=8,threads=1 -vga virtio -display sdl,gl=on
+E:\scoopg\apps\qemu\current\qemu-system-x86_64.exe: OpenGL support is disabled
+```
+
+```
+PS E:\scoopg\apps\qemu\current> E:\scoopg\apps\qemu\current\qemu-system-x86_64.exe --version
+QEMU emulator version 6.0.93 (v6.1.0-rc3-11879-ge232c1bc00-dirty)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+```
+#
diff --git a/results/classifier/108/other/565 b/results/classifier/108/other/565
new file mode 100644
index 000000000..cca02255a
--- /dev/null
+++ b/results/classifier/108/other/565
@@ -0,0 +1,16 @@
+device: 0.843
+permissions: 0.759
+network: 0.756
+other: 0.717
+vnc: 0.657
+debug: 0.573
+socket: 0.553
+performance: 0.405
+graphic: 0.332
+PID: 0.303
+boot: 0.263
+semantic: 0.205
+files: 0.140
+KVM: 0.001
+
+maybe-uninitialized warning in Xtensa flush_window_regs()
diff --git a/results/classifier/108/other/566 b/results/classifier/108/other/566
new file mode 100644
index 000000000..669db6fdf
--- /dev/null
+++ b/results/classifier/108/other/566
@@ -0,0 +1,16 @@
+device: 0.783
+debug: 0.604
+performance: 0.520
+graphic: 0.506
+boot: 0.393
+semantic: 0.388
+PID: 0.356
+network: 0.336
+permissions: 0.263
+files: 0.162
+other: 0.162
+vnc: 0.123
+socket: 0.065
+KVM: 0.029
+
+Fail to build linux-user on Alpine
diff --git a/results/classifier/108/other/567 b/results/classifier/108/other/567
new file mode 100644
index 000000000..e8b7663f2
--- /dev/null
+++ b/results/classifier/108/other/567
@@ -0,0 +1,16 @@
+device: 0.821
+performance: 0.594
+graphic: 0.488
+network: 0.443
+debug: 0.415
+permissions: 0.351
+semantic: 0.341
+boot: 0.318
+files: 0.317
+vnc: 0.267
+PID: 0.197
+socket: 0.098
+other: 0.042
+KVM: 0.012
+
+qemu 6.1.0 build fail on alpine linux
diff --git a/results/classifier/108/other/568 b/results/classifier/108/other/568
new file mode 100644
index 000000000..2cfc4a295
--- /dev/null
+++ b/results/classifier/108/other/568
@@ -0,0 +1,41 @@
+graphic: 0.858
+semantic: 0.796
+device: 0.733
+debug: 0.724
+performance: 0.683
+PID: 0.605
+socket: 0.473
+permissions: 0.456
+vnc: 0.364
+files: 0.334
+other: 0.158
+boot: 0.154
+network: 0.112
+KVM: 0.072
+
+video memory option not working with Mac OS or Windows guest
+Description of problem:
+The vgamem_mb option tells the guest how much video memory it has access to. When I used this command '-device VGA,vgamem_mb=128', I expect the guest to report there is 128 MB of video memory. What actually happens is the guest does not seem to know how much video memory is actually available.
+Steps to reproduce:
+**Mac OS guest:**
+1. Run a Mac OS guest with this command: -device VGA,vgamem_mb=128
+2. In Mac OS X open the System Information application -> /Applications/Utilities/System Information. 
+3. Click on "Graphics/Displays".
+4. Look at the 'VRAM (Total)' field.
+The field only shows 3 MB of video ram.
+
+**Windows guest:**
+1. Run a Windows (Windows XP in my case) guest with this command: -device VGA,vgamem_mb=128
+2. Click on Start->Run.
+3. Enter 'dxdiag'.
+4. Push the OK button.
+5. Click on the Display tap in the DirectX Diagnostic Tool.
+6. Look at the Approv. Total Memory field.
+The field should say 128 MB but actually says N/A.
+Additional information:
+**Mac OS 8.5<br>**
+![Mac_OS_10.8](/uploads/b80d67c82ec1236067b3577add10c19c/Mac_OS_10.8.png)<br><br><br>
+**Windows XP<br>**
+![Windows_XP](/uploads/9db71f35faa360dfcebc2b8af84abf06/Windows_XP.png)<br><br><br>
+**Windows 7<br>**
+![Windows_7](/uploads/8645f1424ef1637300056c889df3d7de/Windows_7.png)
diff --git a/results/classifier/108/other/568053 b/results/classifier/108/other/568053
new file mode 100644
index 000000000..a1ddc3fa3
--- /dev/null
+++ b/results/classifier/108/other/568053
@@ -0,0 +1,26 @@
+graphic: 0.805
+semantic: 0.767
+device: 0.547
+network: 0.432
+other: 0.425
+files: 0.414
+permissions: 0.285
+performance: 0.278
+socket: 0.255
+debug: 0.193
+PID: 0.177
+vnc: 0.151
+boot: 0.136
+KVM: 0.019
+
+requires MSYS coreutils ext sub-package to build on Windows
+
+When I try to build QEMU on Windows without the MSYS coreutils ext sub-package installed, the build fails because it cannot find dd.
+
+
+
+pc-bios/optionrom/signrom.sh uses 'dd'.
+
+signrom.sh has been removed/rewritten by this commit:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=0d6b9cc7420dd2d531b48508f0d4
+
diff --git a/results/classifier/108/other/568614 b/results/classifier/108/other/568614
new file mode 100644
index 000000000..6df66e27e
--- /dev/null
+++ b/results/classifier/108/other/568614
@@ -0,0 +1,102 @@
+semantic: 0.910
+other: 0.906
+permissions: 0.892
+performance: 0.855
+socket: 0.853
+device: 0.847
+KVM: 0.840
+PID: 0.833
+graphic: 0.827
+debug: 0.813
+vnc: 0.799
+files: 0.773
+network: 0.732
+boot: 0.728
+
+x86_64 host curses interface: spacing/garbling
+
+Environment:
+Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3
+
+Steps to reproduce:
+1. Have a host system running 64-bit Linux.
+2. Start a qemu VM with the -curses flag.
+
+Expected results:
+Text displayed looks as it would on a real text-mode display, and VM is therefore usable.
+
+Actual results:
+Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible.
+
+The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine.  I don't know enough of the semantics of console_ch_t to know if this is the "correct" fix or if there should be, say, an extra cast somewhere instead.
+
+
+
+Just compiled qemu from git to check for bug, and it is still present.
+
+This patch should address the problem.  I've submitted it to qemu-devel.
+
+Perhaps you have found an endianness bug as well, but my issue is with word size (my host is a 64-bit Intel).  I manually applied the patch to a 0.12.3 build, and I am still seeing the problem with the curses console.
+
+It seems that the console_ch_t type is used in a number of different contexts.  The console.c and console.h files use console_ch_t fairly uniformly.  However, the `screen' array in curses.c is cast to both uint8_t* and chtype* (unsigned int* according to my curses library) and passed as console_ch_t* (unsigned long*) to vga_hw_text_update.  That's three different bit-sizes on my machine... is it possible that the problem lies here?
+
+Hi Devin,
+
+Can you test if this bug still exists with 0.14 (or better still, a git build)?
+
+Brad
+
+
+I just compiled from git and the problem persists.
+
+I will reiterate that the issue appears to be with the word size of the types used, not with endianness; see comment 4.  I have not dug any further into the QEMU code to see if I find a more "correct-looking" solution than the quick patch I have attached to this bug.
+
+any news on that bug?
+
+If I remember correctly, the type is unsigned long because it needs to match "chtype" as declared in curses.h.  On some implementations of curses it may be declared differently, we really should use the "chtype" type directly but console.h is also used when the use of curses was disabled in qemu config.
+
+I'm pretty sure the curses support has been tested on machines of both endianness at one point, but mostly with ncurses only.
+
+I just checked out the ncurses source - it looks like the type of "chtype" actually depends on how ncurses is configured at build time:
+
+curses.h.in:
+#if @cf_cv_enable_lp64@ && defined(_LP64)
+typedef unsigned chtype;
+typedef unsigned mmask_t;
+#else
+typedef unsigned @cf_cv_typeof_chtype@ chtype;
+typedef unsigned @cf_cv_typeof_mmask_t@ mmask_t;
+#endif
+
+So even if Qemu targets only ncurses, we can't assume that chtype is anything in particular.
+
+In light of that, I guess this bug boils down to "let's use chtype directly," which (naively) seems like it could be #ifdef'd pretty easily.
+
+This is probably the source of the problem.  As you say it'd be best to use chtype directly if it can be done cleanly, unfortunately it looks like it'll add a curses specific snippet in console.h, but so be it.  The only other option is to add a conversion step in curses.c and give up zero-copy passing screen data to curses, which I'd like to avoid.
+
+How about using CONFIG_CURSES?  If we --enable-curses, then we know we have curses.h and chtype.  If we --disable-curses, then we don't care.
+
+Patch attached.  It's a no-op if curses is disabled, and it fixes the issue on my machine with curses enabled.  I had to undef the color constants from curses.h so we didn't conflict with enum color_names in console.c.
+
+for which version is the last patch?
+also 12.3?
+
+Pretty sure it was the latest Arch package: 0.14.1.  Did you have trouble applying it?
+
+I can run back and make a patch against git if you can't use this.
+
+no I don't believe it was your fault
+I couldn't get the code compile even without your patch...
+
+man this sucks... i had hoped it would be upstream with 0.15 but I might have to try to compile it by myself again
+
+thanks ;)
+
+Alright, I've sent a patch to qemu-devel.  Let's see what happens now...
+
+ahhhh it worked, just tried it with latest stable 0.15 git !!! finally you are my hero! =)
+
+Fix had been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=df00bed0fa30a6f5712
+... so closing this bug ticket now.
+
diff --git a/results/classifier/108/other/56937788 b/results/classifier/108/other/56937788
new file mode 100644
index 000000000..026b838bf
--- /dev/null
+++ b/results/classifier/108/other/56937788
@@ -0,0 +1,354 @@
+other: 0.791
+KVM: 0.755
+vnc: 0.743
+debug: 0.723
+graphic: 0.720
+semantic: 0.705
+device: 0.697
+performance: 0.692
+permissions: 0.685
+files: 0.680
+boot: 0.636
+network: 0.633
+PID: 0.620
+socket: 0.613
+
+[Qemu-devel] [Bug] virtio-blk: qemu will crash if hotplug virtio-blk device failed
+
+I found that hotplug virtio-blk device will lead to qemu crash.
+
+Re-production steps:
+
+1.       Run VM named vm001
+
+2.       Create a virtio-blk.xml which contains wrong configurations:
+<disk device="lun" rawio="yes" type="block">
+  <driver cache="none" io="native" name="qemu" type="raw" />
+  <source dev="/dev/mapper/11-dm" />
+  <target bus="virtio" dev="vdx" />
+</disk>
+
+3.       Run command : virsh attach-device vm001 vm001
+
+Libvirt will return err msg:
+
+error: Failed to attach device from blk-scsi.xml
+
+error: internal error: unable to execute QEMU command 'device_add': Please set 
+scsi=off for virtio-blk devices in order to use virtio 1.0
+
+it means hotplug virtio-blk device failed.
+
+4.       Suspend or shutdown VM will leads to qemu crash
+
+
+
+from gdb:
+
+
+(gdb) bt
+#0  object_get_class (address@hidden) at qom/object.c:750
+#1  0x00007f9a72582e01 in virtio_vmstate_change (opaque=0x7f9a73d10960, 
+running=0, state=<optimized out>) at 
+/mnt/sdb/lzc/code/open/qemu/hw/virtio/virtio.c:2203
+#2  0x00007f9a7261ef52 in vm_state_notify (address@hidden, address@hidden) at 
+vl.c:1685
+#3  0x00007f9a7252603a in do_vm_stop (state=RUN_STATE_PAUSED) at 
+/mnt/sdb/lzc/code/open/qemu/cpus.c:941
+#4  vm_stop (address@hidden) at /mnt/sdb/lzc/code/open/qemu/cpus.c:1807
+#5  0x00007f9a7262eb1b in qmp_stop (address@hidden) at qmp.c:102
+#6  0x00007f9a7262c70a in qmp_marshal_stop (args=<optimized out>, 
+ret=<optimized out>, errp=0x7ffe63e255d8) at qmp-marshal.c:5854
+#7  0x00007f9a72897e79 in do_qmp_dispatch (errp=0x7ffe63e255d0, 
+request=0x7f9a76510120, cmds=0x7f9a72ee7980 <qmp_commands>) at 
+qapi/qmp-dispatch.c:104
+#8  qmp_dispatch (cmds=0x7f9a72ee7980 <qmp_commands>, address@hidden) at 
+qapi/qmp-dispatch.c:131
+#9  0x00007f9a725288d5 in handle_qmp_command (parser=<optimized out>, 
+tokens=<optimized out>) at /mnt/sdb/lzc/code/open/qemu/monitor.c:3852
+#10 0x00007f9a7289d514 in json_message_process_token (lexer=0x7f9a73ce4498, 
+input=0x7f9a73cc6880, type=JSON_RCURLY, x=36, y=17) at 
+qobject/json-streamer.c:105
+#11 0x00007f9a728bb69b in json_lexer_feed_char (address@hidden, ch=125 '}', 
+address@hidden) at qobject/json-lexer.c:323
+#12 0x00007f9a728bb75e in json_lexer_feed (lexer=0x7f9a73ce4498, 
+buffer=<optimized out>, size=<optimized out>) at qobject/json-lexer.c:373
+#13 0x00007f9a7289d5d9 in json_message_parser_feed (parser=<optimized out>, 
+buffer=<optimized out>, size=<optimized out>) at qobject/json-streamer.c:124
+#14 0x00007f9a7252722e in monitor_qmp_read (opaque=<optimized out>, 
+buf=<optimized out>, size=<optimized out>) at 
+/mnt/sdb/lzc/code/open/qemu/monitor.c:3894
+#15 0x00007f9a7284ee1b in tcp_chr_read (chan=<optimized out>, cond=<optimized 
+out>, opaque=<optimized out>) at chardev/char-socket.c:441
+#16 0x00007f9a6e03e99a in g_main_context_dispatch () from 
+/usr/lib64/libglib-2.0.so.0
+#17 0x00007f9a728a342c in glib_pollfds_poll () at util/main-loop.c:214
+#18 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:261
+#19 main_loop_wait (address@hidden) at util/main-loop.c:515
+#20 0x00007f9a724e7547 in main_loop () at vl.c:1999
+#21 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at 
+vl.c:4877
+
+Problem happens in virtio_vmstate_change which is called by vm_state_notify,
+static void virtio_vmstate_change(void *opaque, int running, RunState state)
+{
+    VirtIODevice *vdev = opaque;
+    BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
+    VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+    bool backend_run = running && (vdev->status & VIRTIO_CONFIG_S_DRIVER_OK);
+    vdev->vm_running = running;
+
+    if (backend_run) {
+        virtio_set_status(vdev, vdev->status);
+    }
+
+    if (k->vmstate_change) {
+        k->vmstate_change(qbus->parent, backend_run);
+    }
+
+    if (!backend_run) {
+        virtio_set_status(vdev, vdev->status);
+    }
+}
+
+Vdev's parent_bus is NULL, so qdev_get_parent_bus(DEVICE(vdev)) will crash.
+virtio_vmstate_change is added to the list vm_change_state_head at 
+virtio_blk_device_realize(virtio_init),
+but after hotplug virtio-blk failed, virtio_vmstate_change will not be removed 
+from vm_change_state_head.
+
+
+I apply a patch as follews:
+
+diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
+index 5884ce3..ea532dc 100644
+--- a/hw/virtio/virtio.c
++++ b/hw/virtio/virtio.c
+@@ -2491,6 +2491,7 @@ static void virtio_device_realize(DeviceState *dev, Error 
+**errp)
+     virtio_bus_device_plugged(vdev, &err);
+     if (err != NULL) {
+         error_propagate(errp, err);
++        vdc->unrealize(dev, NULL);
+         return;
+     }
+
+On Tue, Oct 31, 2017 at 05:19:08AM +0000, linzhecheng wrote:
+>
+I found that hotplug virtio-blk device will lead to qemu crash.
+The author posted a patch in a separate email thread.  Please see
+"[PATCH] fix: unrealize virtio device if we fail to hotplug it".
+
+>
+Re-production steps:
+>
+>
+1.       Run VM named vm001
+>
+>
+2.       Create a virtio-blk.xml which contains wrong configurations:
+>
+<disk device="lun" rawio="yes" type="block">
+>
+<driver cache="none" io="native" name="qemu" type="raw" />
+>
+<source dev="/dev/mapper/11-dm" />
+>
+<target bus="virtio" dev="vdx" />
+>
+</disk>
+>
+>
+3.       Run command : virsh attach-device vm001 vm001
+>
+>
+Libvirt will return err msg:
+>
+>
+error: Failed to attach device from blk-scsi.xml
+>
+>
+error: internal error: unable to execute QEMU command 'device_add': Please
+>
+set scsi=off for virtio-blk devices in order to use virtio 1.0
+>
+>
+it means hotplug virtio-blk device failed.
+>
+>
+4.       Suspend or shutdown VM will leads to qemu crash
+>
+>
+>
+>
+from gdb:
+>
+>
+>
+(gdb) bt
+>
+#0  object_get_class (address@hidden) at qom/object.c:750
+>
+#1  0x00007f9a72582e01 in virtio_vmstate_change (opaque=0x7f9a73d10960,
+>
+running=0, state=<optimized out>) at
+>
+/mnt/sdb/lzc/code/open/qemu/hw/virtio/virtio.c:2203
+>
+#2  0x00007f9a7261ef52 in vm_state_notify (address@hidden, address@hidden) at
+>
+vl.c:1685
+>
+#3  0x00007f9a7252603a in do_vm_stop (state=RUN_STATE_PAUSED) at
+>
+/mnt/sdb/lzc/code/open/qemu/cpus.c:941
+>
+#4  vm_stop (address@hidden) at /mnt/sdb/lzc/code/open/qemu/cpus.c:1807
+>
+#5  0x00007f9a7262eb1b in qmp_stop (address@hidden) at qmp.c:102
+>
+#6  0x00007f9a7262c70a in qmp_marshal_stop (args=<optimized out>,
+>
+ret=<optimized out>, errp=0x7ffe63e255d8) at qmp-marshal.c:5854
+>
+#7  0x00007f9a72897e79 in do_qmp_dispatch (errp=0x7ffe63e255d0,
+>
+request=0x7f9a76510120, cmds=0x7f9a72ee7980 <qmp_commands>) at
+>
+qapi/qmp-dispatch.c:104
+>
+#8  qmp_dispatch (cmds=0x7f9a72ee7980 <qmp_commands>, address@hidden) at
+>
+qapi/qmp-dispatch.c:131
+>
+#9  0x00007f9a725288d5 in handle_qmp_command (parser=<optimized out>,
+>
+tokens=<optimized out>) at /mnt/sdb/lzc/code/open/qemu/monitor.c:3852
+>
+#10 0x00007f9a7289d514 in json_message_process_token (lexer=0x7f9a73ce4498,
+>
+input=0x7f9a73cc6880, type=JSON_RCURLY, x=36, y=17) at
+>
+qobject/json-streamer.c:105
+>
+#11 0x00007f9a728bb69b in json_lexer_feed_char (address@hidden, ch=125 '}',
+>
+address@hidden) at qobject/json-lexer.c:323
+>
+#12 0x00007f9a728bb75e in json_lexer_feed (lexer=0x7f9a73ce4498,
+>
+buffer=<optimized out>, size=<optimized out>) at qobject/json-lexer.c:373
+>
+#13 0x00007f9a7289d5d9 in json_message_parser_feed (parser=<optimized out>,
+>
+buffer=<optimized out>, size=<optimized out>) at qobject/json-streamer.c:124
+>
+#14 0x00007f9a7252722e in monitor_qmp_read (opaque=<optimized out>,
+>
+buf=<optimized out>, size=<optimized out>) at
+>
+/mnt/sdb/lzc/code/open/qemu/monitor.c:3894
+>
+#15 0x00007f9a7284ee1b in tcp_chr_read (chan=<optimized out>, cond=<optimized
+>
+out>, opaque=<optimized out>) at chardev/char-socket.c:441
+>
+#16 0x00007f9a6e03e99a in g_main_context_dispatch () from
+>
+/usr/lib64/libglib-2.0.so.0
+>
+#17 0x00007f9a728a342c in glib_pollfds_poll () at util/main-loop.c:214
+>
+#18 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:261
+>
+#19 main_loop_wait (address@hidden) at util/main-loop.c:515
+>
+#20 0x00007f9a724e7547 in main_loop () at vl.c:1999
+>
+#21 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
+>
+at vl.c:4877
+>
+>
+Problem happens in virtio_vmstate_change which is called by vm_state_notify,
+>
+static void virtio_vmstate_change(void *opaque, int running, RunState state)
+>
+{
+>
+VirtIODevice *vdev = opaque;
+>
+BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
+>
+VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
+>
+bool backend_run = running && (vdev->status & VIRTIO_CONFIG_S_DRIVER_OK);
+>
+vdev->vm_running = running;
+>
+>
+if (backend_run) {
+>
+virtio_set_status(vdev, vdev->status);
+>
+}
+>
+>
+if (k->vmstate_change) {
+>
+k->vmstate_change(qbus->parent, backend_run);
+>
+}
+>
+>
+if (!backend_run) {
+>
+virtio_set_status(vdev, vdev->status);
+>
+}
+>
+}
+>
+>
+Vdev's parent_bus is NULL, so qdev_get_parent_bus(DEVICE(vdev)) will crash.
+>
+virtio_vmstate_change is added to the list vm_change_state_head at
+>
+virtio_blk_device_realize(virtio_init),
+>
+but after hotplug virtio-blk failed, virtio_vmstate_change will not be
+>
+removed from vm_change_state_head.
+>
+>
+>
+I apply a patch as follews:
+>
+>
+diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
+>
+index 5884ce3..ea532dc 100644
+>
+--- a/hw/virtio/virtio.c
+>
++++ b/hw/virtio/virtio.c
+>
+@@ -2491,6 +2491,7 @@ static void virtio_device_realize(DeviceState *dev,
+>
+Error **errp)
+>
+virtio_bus_device_plugged(vdev, &err);
+>
+if (err != NULL) {
+>
+error_propagate(errp, err);
+>
++        vdc->unrealize(dev, NULL);
+>
+return;
+>
+}
+signature.asc
+Description:
+PGP signature
+