From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/zero-shot/118/peripherals/102   |  31 ++
 .../classifier/zero-shot/118/peripherals/1034423   | 384 ++++++++++++++
 .../classifier/zero-shot/118/peripherals/1047470   |  98 ++++
 .../classifier/zero-shot/118/peripherals/1096713   |  43 ++
 .../classifier/zero-shot/118/peripherals/1096714   |  64 +++
 results/classifier/zero-shot/118/peripherals/1168  |  43 ++
 .../classifier/zero-shot/118/peripherals/1205156   | 280 ++++++++++
 .../classifier/zero-shot/118/peripherals/1219207   |  92 ++++
 .../classifier/zero-shot/118/peripherals/1245703   | 108 ++++
 results/classifier/zero-shot/118/peripherals/1250  |  33 ++
 results/classifier/zero-shot/118/peripherals/126   |  31 ++
 .../classifier/zero-shot/118/peripherals/1311614   | 152 ++++++
 .../classifier/zero-shot/118/peripherals/1357226   |  97 ++++
 results/classifier/zero-shot/118/peripherals/136   |  31 ++
 .../classifier/zero-shot/118/peripherals/1381879   |  68 +++
 .../classifier/zero-shot/118/peripherals/1410288   |  96 ++++
 results/classifier/zero-shot/118/peripherals/144   |  31 ++
 results/classifier/zero-shot/118/peripherals/1444  |  72 +++
 .../classifier/zero-shot/118/peripherals/1496384   |  52 ++
 results/classifier/zero-shot/118/peripherals/1504  |  31 ++
 results/classifier/zero-shot/118/peripherals/1532  | 533 +++++++++++++++++++
 .../classifier/zero-shot/118/peripherals/1538541   |  95 ++++
 .../classifier/zero-shot/118/peripherals/1547526   | 447 ++++++++++++++++
 .../classifier/zero-shot/118/peripherals/1558175   | 583 +++++++++++++++++++++
 results/classifier/zero-shot/118/peripherals/1568  |  69 +++
 results/classifier/zero-shot/118/peripherals/157   |  31 ++
 .../classifier/zero-shot/118/peripherals/1585008   |  81 +++
 .../classifier/zero-shot/118/peripherals/1596009   |  70 +++
 .../classifier/zero-shot/118/peripherals/1596204   |  56 ++
 results/classifier/zero-shot/118/peripherals/1597  |  86 +++
 .../classifier/zero-shot/118/peripherals/1634852   |  79 +++
 .../classifier/zero-shot/118/peripherals/1637693   |  83 +++
 .../classifier/zero-shot/118/peripherals/1643342   |  56 ++
 .../classifier/zero-shot/118/peripherals/1653063   |  99 ++++
 .../classifier/zero-shot/118/peripherals/1667613   |  49 ++
 .../classifier/zero-shot/118/peripherals/1673722   | 143 +++++
 .../classifier/zero-shot/118/peripherals/1675458   | 111 ++++
 results/classifier/zero-shot/118/peripherals/168   |  31 ++
 results/classifier/zero-shot/118/peripherals/1699  |  31 ++
 .../classifier/zero-shot/118/peripherals/1701449   | 109 ++++
 .../classifier/zero-shot/118/peripherals/1711316   | 114 ++++
 .../classifier/zero-shot/118/peripherals/1731277   |  71 +++
 .../classifier/zero-shot/118/peripherals/1732679   | 126 +++++
 .../classifier/zero-shot/118/peripherals/1762707   |  68 +++
 .../classifier/zero-shot/118/peripherals/1770417   |  84 +++
 .../classifier/zero-shot/118/peripherals/1771042   |  98 ++++
 .../classifier/zero-shot/118/peripherals/1778966   |  66 +++
 .../classifier/zero-shot/118/peripherals/1787505   | 125 +++++
 results/classifier/zero-shot/118/peripherals/1801  |  81 +++
 .../classifier/zero-shot/118/peripherals/1801674   | 112 ++++
 .../classifier/zero-shot/118/peripherals/1802684   | 201 +++++++
 .../classifier/zero-shot/118/peripherals/1804323   | 172 ++++++
 .../classifier/zero-shot/118/peripherals/1828508   | 125 +++++
 results/classifier/zero-shot/118/peripherals/183   |  31 ++
 .../classifier/zero-shot/118/peripherals/1833204   | 154 ++++++
 results/classifier/zero-shot/118/peripherals/1834  | 214 ++++++++
 .../classifier/zero-shot/118/peripherals/1835466   | 280 ++++++++++
 .../classifier/zero-shot/118/peripherals/1836136   |  42 ++
 .../classifier/zero-shot/118/peripherals/1842925   | 152 ++++++
 .../classifier/zero-shot/118/peripherals/1843852   | 106 ++++
 results/classifier/zero-shot/118/peripherals/1851  | 465 ++++++++++++++++
 .../classifier/zero-shot/118/peripherals/1851095   | 102 ++++
 .../classifier/zero-shot/118/peripherals/1852196   | 112 ++++
 .../classifier/zero-shot/118/peripherals/1855535   |  88 ++++
 results/classifier/zero-shot/118/peripherals/1863  | 102 ++++
 .../classifier/zero-shot/118/peripherals/1863200   | 122 +++++
 results/classifier/zero-shot/118/peripherals/1866  |  31 ++
 .../classifier/zero-shot/118/peripherals/1869858   |  45 ++
 .../classifier/zero-shot/118/peripherals/1874678   |  87 +++
 .../classifier/zero-shot/118/peripherals/1878501   | 108 ++++
 .../classifier/zero-shot/118/peripherals/1881506   |  66 +++
 .../classifier/zero-shot/118/peripherals/1883268   | 129 +++++
 .../classifier/zero-shot/118/peripherals/1886097   | 101 ++++
 .../classifier/zero-shot/118/peripherals/1888492   |  99 ++++
 .../classifier/zero-shot/118/peripherals/1889943   | 398 ++++++++++++++
 .../classifier/zero-shot/118/peripherals/1890155   |  79 +++
 .../classifier/zero-shot/118/peripherals/1893003   | 109 ++++
 .../classifier/zero-shot/118/peripherals/1907817   |  82 +++
 .../classifier/zero-shot/118/peripherals/1907938   | 114 ++++
 .../classifier/zero-shot/118/peripherals/1910941   | 160 ++++++
 results/classifier/zero-shot/118/peripherals/1911  |  70 +++
 .../classifier/zero-shot/118/peripherals/1912780   | 214 ++++++++
 .../classifier/zero-shot/118/peripherals/1913344   |  43 ++
 .../classifier/zero-shot/118/peripherals/1916655   |  85 +++
 .../classifier/zero-shot/118/peripherals/1917085   |  97 ++++
 results/classifier/zero-shot/118/peripherals/193   |  31 ++
 .../classifier/zero-shot/118/peripherals/1970563   | 149 ++++++
 results/classifier/zero-shot/118/peripherals/198   |  31 ++
 results/classifier/zero-shot/118/peripherals/1982  |  39 ++
 results/classifier/zero-shot/118/peripherals/2027  | 263 ++++++++++
 results/classifier/zero-shot/118/peripherals/2178  |  47 ++
 results/classifier/zero-shot/118/peripherals/2181  |  33 ++
 results/classifier/zero-shot/118/peripherals/2256  |  31 ++
 results/classifier/zero-shot/118/peripherals/2307  |  69 +++
 results/classifier/zero-shot/118/peripherals/2308  | 109 ++++
 results/classifier/zero-shot/118/peripherals/2349  |  42 ++
 results/classifier/zero-shot/118/peripherals/2440  | 142 +++++
 results/classifier/zero-shot/118/peripherals/2448  |  76 +++
 results/classifier/zero-shot/118/peripherals/2462  |  69 +++
 results/classifier/zero-shot/118/peripherals/2485  |  77 +++
 results/classifier/zero-shot/118/peripherals/2487  |  98 ++++
 results/classifier/zero-shot/118/peripherals/2498  |  81 +++
 results/classifier/zero-shot/118/peripherals/2521  |  46 ++
 results/classifier/zero-shot/118/peripherals/2589  |  86 +++
 results/classifier/zero-shot/118/peripherals/2694  |  54 ++
 results/classifier/zero-shot/118/peripherals/2705  |  47 ++
 results/classifier/zero-shot/118/peripherals/2788  |  43 ++
 results/classifier/zero-shot/118/peripherals/2826  |  39 ++
 results/classifier/zero-shot/118/peripherals/2860  |  63 +++
 results/classifier/zero-shot/118/peripherals/2864  |  39 ++
 results/classifier/zero-shot/118/peripherals/2888  |  44 ++
 results/classifier/zero-shot/118/peripherals/2889  |  52 ++
 results/classifier/zero-shot/118/peripherals/2928  |  86 +++
 results/classifier/zero-shot/118/peripherals/2948  |  43 ++
 results/classifier/zero-shot/118/peripherals/2976  |  55 ++
 results/classifier/zero-shot/118/peripherals/298   |  31 ++
 results/classifier/zero-shot/118/peripherals/317   |  31 ++
 results/classifier/zero-shot/118/peripherals/391   |  31 ++
 results/classifier/zero-shot/118/peripherals/446   |  31 ++
 results/classifier/zero-shot/118/peripherals/530   |  73 +++
 results/classifier/zero-shot/118/peripherals/545   |  31 ++
 results/classifier/zero-shot/118/peripherals/561   |  31 ++
 results/classifier/zero-shot/118/peripherals/569   |  31 ++
 .../classifier/zero-shot/118/peripherals/56937788  | 369 +++++++++++++
 results/classifier/zero-shot/118/peripherals/585   |  31 ++
 .../classifier/zero-shot/118/peripherals/588731    | 184 +++++++
 results/classifier/zero-shot/118/peripherals/595   |  41 ++
 .../classifier/zero-shot/118/peripherals/60339453  |  86 +++
 .../classifier/zero-shot/118/peripherals/612297    |  48 ++
 results/classifier/zero-shot/118/peripherals/615   |  40 ++
 results/classifier/zero-shot/118/peripherals/629   |  40 ++
 results/classifier/zero-shot/118/peripherals/641   |  31 ++
 results/classifier/zero-shot/118/peripherals/651   |  31 ++
 results/classifier/zero-shot/118/peripherals/685   |  99 ++++
 results/classifier/zero-shot/118/peripherals/752   |  43 ++
 .../classifier/zero-shot/118/peripherals/754635    | 100 ++++
 .../classifier/zero-shot/118/peripherals/795866    | 184 +++++++
 .../classifier/zero-shot/118/peripherals/813546    |  46 ++
 results/classifier/zero-shot/118/peripherals/830   |  31 ++
 results/classifier/zero-shot/118/peripherals/863   |  84 +++
 results/classifier/zero-shot/118/peripherals/865   |  75 +++
 .../classifier/zero-shot/118/peripherals/881637    |  51 ++
 .../classifier/zero-shot/118/peripherals/897750    | 405 ++++++++++++++
 results/classifier/zero-shot/118/peripherals/899   |  44 ++
 results/classifier/zero-shot/118/peripherals/918   |  31 ++
 results/classifier/zero-shot/118/peripherals/93    |  31 ++
 results/classifier/zero-shot/118/peripherals/937   |  98 ++++
 .../classifier/zero-shot/118/peripherals/938552    |  58 ++
 results/classifier/zero-shot/118/peripherals/98    |  31 ++
 149 files changed, 14895 insertions(+)
 create mode 100644 results/classifier/zero-shot/118/peripherals/102
 create mode 100644 results/classifier/zero-shot/118/peripherals/1034423
 create mode 100644 results/classifier/zero-shot/118/peripherals/1047470
 create mode 100644 results/classifier/zero-shot/118/peripherals/1096713
 create mode 100644 results/classifier/zero-shot/118/peripherals/1096714
 create mode 100644 results/classifier/zero-shot/118/peripherals/1168
 create mode 100644 results/classifier/zero-shot/118/peripherals/1205156
 create mode 100644 results/classifier/zero-shot/118/peripherals/1219207
 create mode 100644 results/classifier/zero-shot/118/peripherals/1245703
 create mode 100644 results/classifier/zero-shot/118/peripherals/1250
 create mode 100644 results/classifier/zero-shot/118/peripherals/126
 create mode 100644 results/classifier/zero-shot/118/peripherals/1311614
 create mode 100644 results/classifier/zero-shot/118/peripherals/1357226
 create mode 100644 results/classifier/zero-shot/118/peripherals/136
 create mode 100644 results/classifier/zero-shot/118/peripherals/1381879
 create mode 100644 results/classifier/zero-shot/118/peripherals/1410288
 create mode 100644 results/classifier/zero-shot/118/peripherals/144
 create mode 100644 results/classifier/zero-shot/118/peripherals/1444
 create mode 100644 results/classifier/zero-shot/118/peripherals/1496384
 create mode 100644 results/classifier/zero-shot/118/peripherals/1504
 create mode 100644 results/classifier/zero-shot/118/peripherals/1532
 create mode 100644 results/classifier/zero-shot/118/peripherals/1538541
 create mode 100644 results/classifier/zero-shot/118/peripherals/1547526
 create mode 100644 results/classifier/zero-shot/118/peripherals/1558175
 create mode 100644 results/classifier/zero-shot/118/peripherals/1568
 create mode 100644 results/classifier/zero-shot/118/peripherals/157
 create mode 100644 results/classifier/zero-shot/118/peripherals/1585008
 create mode 100644 results/classifier/zero-shot/118/peripherals/1596009
 create mode 100644 results/classifier/zero-shot/118/peripherals/1596204
 create mode 100644 results/classifier/zero-shot/118/peripherals/1597
 create mode 100644 results/classifier/zero-shot/118/peripherals/1634852
 create mode 100644 results/classifier/zero-shot/118/peripherals/1637693
 create mode 100644 results/classifier/zero-shot/118/peripherals/1643342
 create mode 100644 results/classifier/zero-shot/118/peripherals/1653063
 create mode 100644 results/classifier/zero-shot/118/peripherals/1667613
 create mode 100644 results/classifier/zero-shot/118/peripherals/1673722
 create mode 100644 results/classifier/zero-shot/118/peripherals/1675458
 create mode 100644 results/classifier/zero-shot/118/peripherals/168
 create mode 100644 results/classifier/zero-shot/118/peripherals/1699
 create mode 100644 results/classifier/zero-shot/118/peripherals/1701449
 create mode 100644 results/classifier/zero-shot/118/peripherals/1711316
 create mode 100644 results/classifier/zero-shot/118/peripherals/1731277
 create mode 100644 results/classifier/zero-shot/118/peripherals/1732679
 create mode 100644 results/classifier/zero-shot/118/peripherals/1762707
 create mode 100644 results/classifier/zero-shot/118/peripherals/1770417
 create mode 100644 results/classifier/zero-shot/118/peripherals/1771042
 create mode 100644 results/classifier/zero-shot/118/peripherals/1778966
 create mode 100644 results/classifier/zero-shot/118/peripherals/1787505
 create mode 100644 results/classifier/zero-shot/118/peripherals/1801
 create mode 100644 results/classifier/zero-shot/118/peripherals/1801674
 create mode 100644 results/classifier/zero-shot/118/peripherals/1802684
 create mode 100644 results/classifier/zero-shot/118/peripherals/1804323
 create mode 100644 results/classifier/zero-shot/118/peripherals/1828508
 create mode 100644 results/classifier/zero-shot/118/peripherals/183
 create mode 100644 results/classifier/zero-shot/118/peripherals/1833204
 create mode 100644 results/classifier/zero-shot/118/peripherals/1834
 create mode 100644 results/classifier/zero-shot/118/peripherals/1835466
 create mode 100644 results/classifier/zero-shot/118/peripherals/1836136
 create mode 100644 results/classifier/zero-shot/118/peripherals/1842925
 create mode 100644 results/classifier/zero-shot/118/peripherals/1843852
 create mode 100644 results/classifier/zero-shot/118/peripherals/1851
 create mode 100644 results/classifier/zero-shot/118/peripherals/1851095
 create mode 100644 results/classifier/zero-shot/118/peripherals/1852196
 create mode 100644 results/classifier/zero-shot/118/peripherals/1855535
 create mode 100644 results/classifier/zero-shot/118/peripherals/1863
 create mode 100644 results/classifier/zero-shot/118/peripherals/1863200
 create mode 100644 results/classifier/zero-shot/118/peripherals/1866
 create mode 100644 results/classifier/zero-shot/118/peripherals/1869858
 create mode 100644 results/classifier/zero-shot/118/peripherals/1874678
 create mode 100644 results/classifier/zero-shot/118/peripherals/1878501
 create mode 100644 results/classifier/zero-shot/118/peripherals/1881506
 create mode 100644 results/classifier/zero-shot/118/peripherals/1883268
 create mode 100644 results/classifier/zero-shot/118/peripherals/1886097
 create mode 100644 results/classifier/zero-shot/118/peripherals/1888492
 create mode 100644 results/classifier/zero-shot/118/peripherals/1889943
 create mode 100644 results/classifier/zero-shot/118/peripherals/1890155
 create mode 100644 results/classifier/zero-shot/118/peripherals/1893003
 create mode 100644 results/classifier/zero-shot/118/peripherals/1907817
 create mode 100644 results/classifier/zero-shot/118/peripherals/1907938
 create mode 100644 results/classifier/zero-shot/118/peripherals/1910941
 create mode 100644 results/classifier/zero-shot/118/peripherals/1911
 create mode 100644 results/classifier/zero-shot/118/peripherals/1912780
 create mode 100644 results/classifier/zero-shot/118/peripherals/1913344
 create mode 100644 results/classifier/zero-shot/118/peripherals/1916655
 create mode 100644 results/classifier/zero-shot/118/peripherals/1917085
 create mode 100644 results/classifier/zero-shot/118/peripherals/193
 create mode 100644 results/classifier/zero-shot/118/peripherals/1970563
 create mode 100644 results/classifier/zero-shot/118/peripherals/198
 create mode 100644 results/classifier/zero-shot/118/peripherals/1982
 create mode 100644 results/classifier/zero-shot/118/peripherals/2027
 create mode 100644 results/classifier/zero-shot/118/peripherals/2178
 create mode 100644 results/classifier/zero-shot/118/peripherals/2181
 create mode 100644 results/classifier/zero-shot/118/peripherals/2256
 create mode 100644 results/classifier/zero-shot/118/peripherals/2307
 create mode 100644 results/classifier/zero-shot/118/peripherals/2308
 create mode 100644 results/classifier/zero-shot/118/peripherals/2349
 create mode 100644 results/classifier/zero-shot/118/peripherals/2440
 create mode 100644 results/classifier/zero-shot/118/peripherals/2448
 create mode 100644 results/classifier/zero-shot/118/peripherals/2462
 create mode 100644 results/classifier/zero-shot/118/peripherals/2485
 create mode 100644 results/classifier/zero-shot/118/peripherals/2487
 create mode 100644 results/classifier/zero-shot/118/peripherals/2498
 create mode 100644 results/classifier/zero-shot/118/peripherals/2521
 create mode 100644 results/classifier/zero-shot/118/peripherals/2589
 create mode 100644 results/classifier/zero-shot/118/peripherals/2694
 create mode 100644 results/classifier/zero-shot/118/peripherals/2705
 create mode 100644 results/classifier/zero-shot/118/peripherals/2788
 create mode 100644 results/classifier/zero-shot/118/peripherals/2826
 create mode 100644 results/classifier/zero-shot/118/peripherals/2860
 create mode 100644 results/classifier/zero-shot/118/peripherals/2864
 create mode 100644 results/classifier/zero-shot/118/peripherals/2888
 create mode 100644 results/classifier/zero-shot/118/peripherals/2889
 create mode 100644 results/classifier/zero-shot/118/peripherals/2928
 create mode 100644 results/classifier/zero-shot/118/peripherals/2948
 create mode 100644 results/classifier/zero-shot/118/peripherals/2976
 create mode 100644 results/classifier/zero-shot/118/peripherals/298
 create mode 100644 results/classifier/zero-shot/118/peripherals/317
 create mode 100644 results/classifier/zero-shot/118/peripherals/391
 create mode 100644 results/classifier/zero-shot/118/peripherals/446
 create mode 100644 results/classifier/zero-shot/118/peripherals/530
 create mode 100644 results/classifier/zero-shot/118/peripherals/545
 create mode 100644 results/classifier/zero-shot/118/peripherals/561
 create mode 100644 results/classifier/zero-shot/118/peripherals/569
 create mode 100644 results/classifier/zero-shot/118/peripherals/56937788
 create mode 100644 results/classifier/zero-shot/118/peripherals/585
 create mode 100644 results/classifier/zero-shot/118/peripherals/588731
 create mode 100644 results/classifier/zero-shot/118/peripherals/595
 create mode 100644 results/classifier/zero-shot/118/peripherals/60339453
 create mode 100644 results/classifier/zero-shot/118/peripherals/612297
 create mode 100644 results/classifier/zero-shot/118/peripherals/615
 create mode 100644 results/classifier/zero-shot/118/peripherals/629
 create mode 100644 results/classifier/zero-shot/118/peripherals/641
 create mode 100644 results/classifier/zero-shot/118/peripherals/651
 create mode 100644 results/classifier/zero-shot/118/peripherals/685
 create mode 100644 results/classifier/zero-shot/118/peripherals/752
 create mode 100644 results/classifier/zero-shot/118/peripherals/754635
 create mode 100644 results/classifier/zero-shot/118/peripherals/795866
 create mode 100644 results/classifier/zero-shot/118/peripherals/813546
 create mode 100644 results/classifier/zero-shot/118/peripherals/830
 create mode 100644 results/classifier/zero-shot/118/peripherals/863
 create mode 100644 results/classifier/zero-shot/118/peripherals/865
 create mode 100644 results/classifier/zero-shot/118/peripherals/881637
 create mode 100644 results/classifier/zero-shot/118/peripherals/897750
 create mode 100644 results/classifier/zero-shot/118/peripherals/899
 create mode 100644 results/classifier/zero-shot/118/peripherals/918
 create mode 100644 results/classifier/zero-shot/118/peripherals/93
 create mode 100644 results/classifier/zero-shot/118/peripherals/937
 create mode 100644 results/classifier/zero-shot/118/peripherals/938552
 create mode 100644 results/classifier/zero-shot/118/peripherals/98

(limited to 'results/classifier/zero-shot/118/peripherals')

diff --git a/results/classifier/zero-shot/118/peripherals/102 b/results/classifier/zero-shot/118/peripherals/102
new file mode 100644
index 00000000..acc9453b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/102
@@ -0,0 +1,31 @@
+peripherals: 0.964
+device: 0.920
+performance: 0.747
+VMM: 0.743
+debug: 0.721
+mistranslation: 0.595
+graphic: 0.541
+ppc: 0.394
+semantic: 0.369
+architecture: 0.289
+permissions: 0.260
+PID: 0.242
+TCG: 0.222
+boot: 0.214
+files: 0.190
+user-level: 0.164
+register: 0.137
+assembly: 0.132
+virtual: 0.128
+i386: 0.118
+vnc: 0.072
+risc-v: 0.068
+network: 0.040
+KVM: 0.034
+x86: 0.030
+socket: 0.013
+hypervisor: 0.011
+arm: 0.008
+kernel: 0.004
+
+Mouse stops working when connected usb-storage-device
diff --git a/results/classifier/zero-shot/118/peripherals/1034423 b/results/classifier/zero-shot/118/peripherals/1034423
new file mode 100644
index 00000000..7448ac33
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1034423
@@ -0,0 +1,384 @@
+peripherals: 0.936
+permissions: 0.908
+semantic: 0.905
+VMM: 0.903
+graphic: 0.902
+mistranslation: 0.902
+assembly: 0.897
+network: 0.885
+ppc: 0.880
+device: 0.873
+user-level: 0.861
+architecture: 0.853
+risc-v: 0.850
+KVM: 0.845
+virtual: 0.841
+TCG: 0.833
+PID: 0.832
+hypervisor: 0.830
+vnc: 0.825
+register: 0.824
+socket: 0.822
+kernel: 0.820
+boot: 0.816
+arm: 0.814
+debug: 0.809
+performance: 0.788
+x86: 0.757
+files: 0.754
+i386: 0.624
+
+Guests running OpenIndiana (and relatives) fail to boot on AMD hardware
+
+First observed with OpenSolaris 2009.06, and also applies to the latest OpenIndiana release. 
+
+Version: qemu-kvm 1.1.1
+
+Hardware:
+
+2 x AMD Opteron 6128 8-core processors, 64GB RAM.
+
+These guests boot on equivalent Intel hardware.
+
+To reproduce:
+
+qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-151a5-live-x86.iso -boot order=dc
+
+I've tested with "-vga std" and various different emulated CPU types, to no effect.
+
+What happens:
+
+GRUB loads, and offers multiple boot options, but none work. Some kind of kernel panic flies by very fast before restarting the VM, and careful use of the screenshot button reveals that it reads as follows:
+
+panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault) rp=fec2b48c add r=0
+
+#df Double fault
+pid=0, pc=0xault
+pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
+cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de>
+cr2: 0cr3: ae2f000
+              gs:            1b0    fs:              0   es:         160   ds:          160
+             edi:                0  esi:              0 ebp:             0 esp: fec2b4c4
+             ebx: c0010015 edx:              0 ecx:             0 eax: fec40400
+             trp:                 8  err:              0 eip: fe800377  cs:           158
+             efl:             202 usp: fec40090  ss:           160
+tss.tss_link:     0x0
+tss.tss_esp0:   0x0
+tss.tss_ss0:     0x160
+tss.tss_esp1:   0x0
+tss.tss_ss1:      0x0
+tss.tss esp2:     0x0
+tss.tss_ss2:      0x0
+tss.tss_cr3:       0xae2f000
+tss.tss_eip:       0xfec40400
+tss.tss_eflags:  0x202
+tss.tss_eax:      0xfec40400
+tss.tss_ebx:      0xc0010015
+tss.tss_ecx:      0xc0010000
+tss.tss_edx:      0x0
+tss.tss_esp:      0xfec40090
+
+Warning - stack not written to the dumpbuf
+fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
+fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
+fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)
+
+If there's any more, I haven't managed to catch it. 
+
+Solaris 11 does not seem to suffer from the same issue, although the first message that appears at boot (after the version info) is "trap: Unkown trap type 8 in user mode". Could be related?
+
+As always, thanks in advance and please let me know if I can help to test, or provide any more information.
+
+Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)?
+
+This is an old ticket! I had completely forgotten about it, but will test
+when I get a chance and let you know.
+
+Cheers,
+
+Owen
+
+On Fri, May 19, 2017 at 11:25 AM, Thomas Huth <email address hidden>
+wrote:
+
+> Triaging old bug tickets ... can you still reproduce this issue with the
+> latest version of QEMU (currently v2.9)?
+>
+> ** Changed in: qemu
+>        Status: New => Incomplete
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1034423
+>
+> Title:
+>   Guests running OpenIndiana (and relatives) fail to boot on AMD
+>   hardware
+>
+> Status in QEMU:
+>   Incomplete
+>
+> Bug description:
+>   First observed with OpenSolaris 2009.06, and also applies to the
+>   latest OpenIndiana release.
+>
+>   Version: qemu-kvm 1.1.1
+>
+>   Hardware:
+>
+>   2 x AMD Opteron 6128 8-core processors, 64GB RAM.
+>
+>   These guests boot on equivalent Intel hardware.
+>
+>   To reproduce:
+>
+>   qemu-kvm -nodefaults -m 512 -cpu host -vga cirrus -usbdevice tablet
+>   -vnc :99 -monitor stdio -hda drive.img -cdrom oi-dev-
+>   151a5-live-x86.iso -boot order=dc
+>
+>   I've tested with "-vga std" and various different emulated CPU types,
+>   to no effect.
+>
+>   What happens:
+>
+>   GRUB loads, and offers multiple boot options, but none work. Some kind
+>   of kernel panic flies by very fast before restarting the VM, and
+>   careful use of the screenshot button reveals that it reads as follows:
+>
+>   panic[cpu0]/thread=fec22de0: BAD TRAP: type=8 (#df Double fault)
+>   rp=fec2b48c add r=0
+>
+>   #df Double fault
+>   pid=0, pc=0xault
+>   pid=0, pc=0xfe800377, sp=0xfec40090, eflags=0x202
+>   cr0: 80050011<pg,wp,et,pe> cr4:b8<pge,pae,pse,de>
+>   cr2: 0cr3: ae2f000
+>                 gs:            1b0    fs:              0   es:
+>  160   ds:          160
+>                edi:                0  esi:              0 ebp:
+>  0 esp: fec2b4c4
+>                ebx: c0010015 edx:              0 ecx:             0 eax:
+> fec40400
+>                trp:                 8  err:              0 eip: fe800377
+> cs:           158
+>                efl:             202 usp: fec40090  ss:           160
+>   tss.tss_link:     0x0
+>   tss.tss_esp0:   0x0
+>   tss.tss_ss0:     0x160
+>   tss.tss_esp1:   0x0
+>   tss.tss_ss1:      0x0
+>   tss.tss esp2:     0x0
+>   tss.tss_ss2:      0x0
+>   tss.tss_cr3:       0xae2f000
+>   tss.tss_eip:       0xfec40400
+>   tss.tss_eflags:  0x202
+>   tss.tss_eax:      0xfec40400
+>   tss.tss_ebx:      0xc0010015
+>   tss.tss_ecx:      0xc0010000
+>   tss.tss_edx:      0x0
+>   tss.tss_esp:      0xfec40090
+>
+>   Warning - stack not written to the dumpbuf
+>   fec2b3c8 unix:due+e4 (8, fec2b48c, 0, 0)
+>   fec2b478 unix:trap+12fa (fec2b48c, 0, 0)
+>   fec2b48c unix:_cmntrap+7c (1b0, 0, 160, 160, 0)
+>
+>   If there's any more, I haven't managed to catch it.
+>
+>   Solaris 11 does not seem to suffer from the same issue, although the
+>   first message that appears at boot (after the version info) is "trap:
+>   Unkown trap type 8 in user mode". Could be related?
+>
+>   As always, thanks in advance and please let me know if I can help to
+>   test, or provide any more information.
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1034423/+subscriptions
+>
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Despite the age of the report, I am also reproducing the issue.
+
+I am using Qemu 6.2.0 with KVM on Linux kernel 6.0.5 under Linux Mint 21.
+
+The guest is OpenIndiana Hipster 2021.10.
+
+A guest console capture is attached.
+
+The guest is managed using libvirt 8.0.0
+
+The dump of the libvirt domain configuration is as follows:
+
+<domain type='kvm' id='62'>
+  <name>openindiana</name>
+  <uuid>7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://libosinfo.org/linux/2020"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit='KiB'>2097152</memory>
+  <currentMemory unit='KiB'>2097152</currentMemory>
+  <vcpu placement='static'>4</vcpu>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type>
+    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
+    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana_VARS.fd</nvram>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmport state='off'/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'/>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <pm>
+    <suspend-to-mem enabled='no'/>
+    <suspend-to-disk enabled='no'/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2'/>
+      <source file='/srv/vhd/openindiana.qcow2' index='2'/>
+      <backingStore/>
+      <target dev='sda' bus='sata'/>
+      <alias name='sata0-0-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='1'/>
+      <backingStore/>
+      <target dev='sdb' bus='sata'/>
+      <readonly/>
+      <boot order='1'/>
+      <alias name='sata0-0-1'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
+    </disk>
+    <controller type='usb' index='0' model='ich9-ehci1'>
+      <alias name='usb'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci1'>
+      <alias name='usb'/>
+      <master startport='0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci2'>
+      <alias name='usb'/>
+      <master startport='2'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci3'>
+      <alias name='usb'/>
+      <master startport='4'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'>
+      <alias name='pci.0'/>
+    </controller>
+    <controller type='ide' index='0'>
+      <alias name='ide'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='virtio-serial' index='0'>
+      <alias name='virtio-serial0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <alias name='sata0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
+    </controller>
+    <interface type='network'>
+      <mac address='52:54:00:20:40:9c'/>
+      <source network='default' portid='77a38fbb-c35e-4f78-b377-e823963eb30e' bridge='virbr0'/>
+      <target dev='vnet61'/>
+      <model type='e1000'/>
+      <alias name='net0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <source path='/dev/pts/3'/>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+      <alias name='serial0'/>
+    </serial>
+    <console type='pty' tty='/dev/pts/3'>
+      <source path='/dev/pts/3'/>
+      <target type='serial' port='0'/>
+      <alias name='serial0'/>
+    </console>
+    <channel type='spicevmc'>
+      <target type='virtio' name='com.redhat.spice.0' state='disconnected'/>
+      <alias name='channel0'/>
+      <address type='virtio-serial' controller='0' bus='0' port='1'/>
+    </channel>
+    <input type='tablet' bus='usb'>
+      <alias name='input0'/>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'>
+      <alias name='input1'/>
+    </input>
+    <input type='keyboard' bus='ps2'>
+      <alias name='input2'/>
+    </input>
+    <graphics type='spice'>
+      <listen type='none'/>
+      <image compression='off'/>
+    </graphics>
+    <sound model='ac97'>
+      <alias name='sound0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </sound>
+    <audio id='1' type='spice'/>
+    <video>
+      <model type='vga' vram='16384' heads='1' primary='yes'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <redirdev bus='usb' type='spicevmc'>
+      <alias name='redir0'/>
+      <address type='usb' bus='0' port='2'/>
+    </redirdev>
+    <redirdev bus='usb' type='spicevmc'>
+      <alias name='redir1'/>
+      <address type='usb' bus='0' port='3'/>
+    </redirdev>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </memballoon>
+  </devices>
+  <seclabel type='dynamic' model='apparmor' relabel='yes'>
+    <label>libvirt-7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</label>
+    <imagelabel>libvirt-7a7adcc0-889c-4daf-a73b-21a3fac3d8e7</imagelabel>
+  </seclabel>
+  <seclabel type='dynamic' model='dac' relabel='yes'>
+    <label>+64055:+130</label>
+    <imagelabel>+64055:+130</imagelabel>
+  </seclabel>
+</domain>
+
+
+This bug tracker here is not used anymore. Could you please open a new ticket here:
+
+https://gitlab.com/qemu-project/qemu/-/issues
+
+Thanks!
+
diff --git a/results/classifier/zero-shot/118/peripherals/1047470 b/results/classifier/zero-shot/118/peripherals/1047470
new file mode 100644
index 00000000..5d5db6aa
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1047470
@@ -0,0 +1,98 @@
+peripherals: 0.890
+graphic: 0.869
+socket: 0.863
+network: 0.847
+device: 0.841
+PID: 0.833
+architecture: 0.812
+permissions: 0.809
+debug: 0.806
+semantic: 0.803
+arm: 0.795
+register: 0.781
+virtual: 0.766
+vnc: 0.750
+user-level: 0.742
+KVM: 0.714
+boot: 0.706
+performance: 0.688
+mistranslation: 0.682
+VMM: 0.680
+hypervisor: 0.670
+kernel: 0.600
+risc-v: 0.596
+assembly: 0.565
+ppc: 0.549
+TCG: 0.510
+x86: 0.489
+files: 0.485
+i386: 0.374
+
+qemu/kvm hangs reading from serial console
+
+This is for a qemu-kvm running on RHEL 5, so it's pretty old,
+but i think the problem still exists in 1.2
+
+We have conman running on our hosts, connecting to the
+kvm/qemu's using
+    virsh console
+which just opens up the console /dev/pts/slave that qemu
+opens up when run with options
+    -nographic
+    -serial mon:pty
+
+Sometimes virsh console exits and then qemu locks up.
+My guess is that something like this happens:
+
+virsh console exits
+qemu does a select() on /dev/ptmx (and other FDs)
+select() returns the FD of /dev/ptmx in the read-fdset
+qemu does a read()
+read() returns -1 (EIO)
+qemu does other stuff for a while
+select() ... /dev/ptmx
+read() .. EIO
+other stuff
+select() ... read() ... select() ... read() ... select()
+conman starts a new virsh console that connects
+qemu does a read()
+read() blocks b/c there is now a writer on the tty slave
+
+So i don't see any way around this, given the sorta rudi-
+mentary semantics of TTY IO on Linux (not that i know of
+any platform that does it better ... ?), except ...
+
+maybe qemu should
+    fcntl(master_fd, F_SETFL, flags | O_NONBLOCK) 
+in qemu-char.c:qemu_char_open_pty()
+and be prepared to handle E_WOULDBLOCK|E_AGAIN in 
+qemu-char.c:fd_chr_read() ... ?
+
+--buck
+
+[*] i think, b/c in the old version we are running, sometimes
+    the guest spits out the
+        ^]
+    character to its console, and virsh console reads it and
+    doesn't check to see if its from stdin or the pty and exits, 
+    which, i think, can be fixed like this:
+
+--- libvirt-0.8.2/tools/console.c.ctrl_close_bracket_handling_fix       2012-09-06 10:30:43.606997191 -0400
++++ libvirt-0.8.2/tools/console.c       2012-09-06 10:34:52.154000464 -0400
+@@ -155,6 +155,7 @@ int vshRunConsole(const char *tty) {
+
+                 /* Quit if end of file, or we got the Ctrl-] key */
+                 if (!got ||
++                    fds[i].fd == STDIN_FILENO &&
+                     (got == 1 &&
+                      buf[0] == CTRL_CLOSE_BRACKET))
+                     goto done;
+
+Can you still reproduce this problem with the latest version of QEMU? There have been quite a bunch of fixes in this area in the latest versions...
+
+i don't use kvm/qemu any more and so don't have a means
+to determine if this is still an issue or not so please
+presume fixed, i guess
+
+OK, thanks for your answer!
+
diff --git a/results/classifier/zero-shot/118/peripherals/1096713 b/results/classifier/zero-shot/118/peripherals/1096713
new file mode 100644
index 00000000..3a88a23e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1096713
@@ -0,0 +1,43 @@
+peripherals: 0.912
+graphic: 0.893
+device: 0.866
+i386: 0.713
+mistranslation: 0.692
+ppc: 0.656
+performance: 0.655
+semantic: 0.625
+debug: 0.600
+architecture: 0.591
+network: 0.567
+PID: 0.566
+x86: 0.533
+user-level: 0.530
+register: 0.528
+assembly: 0.507
+kernel: 0.502
+socket: 0.493
+risc-v: 0.460
+vnc: 0.453
+permissions: 0.387
+boot: 0.382
+files: 0.373
+hypervisor: 0.364
+arm: 0.357
+VMM: 0.256
+TCG: 0.218
+virtual: 0.192
+KVM: 0.093
+
+qemu 1.3.0: Windows XP crashes when reconizing the USB keyboard
+
+I'm trying to use the usb tablet and the usb keyboard as follows:
+./qemu-system-i386  -device pci-ohci -device usb-tablet -device usb-kbd
+or
+./qemu-system-i386  -device ich9-usb-ehci1 -device ich9-usb-uhci1 -device usb-tablet -device ich9-usb-uhci2 -device usb-kbd
+
+While Windows XP works fine if I only use the tablet but not the keyboard, it crashed with a BSOD when I use both keyboard and tablet. It crashed during the detection of the keyboard.
+
+Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1096714 b/results/classifier/zero-shot/118/peripherals/1096714
new file mode 100644
index 00000000..5a0633d0
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1096714
@@ -0,0 +1,64 @@
+peripherals: 0.936
+i386: 0.906
+boot: 0.822
+device: 0.809
+ppc: 0.769
+x86: 0.724
+PID: 0.718
+graphic: 0.702
+architecture: 0.677
+performance: 0.586
+register: 0.559
+user-level: 0.531
+semantic: 0.493
+files: 0.481
+vnc: 0.458
+hypervisor: 0.456
+network: 0.435
+kernel: 0.432
+socket: 0.401
+permissions: 0.381
+virtual: 0.368
+VMM: 0.356
+KVM: 0.341
+risc-v: 0.334
+mistranslation: 0.329
+debug: 0.289
+TCG: 0.267
+assembly: 0.256
+arm: 0.229
+
+qemu 1.3.0: usb devices shouldn't have same vendor/product ID and same serial
+
+Boot Windows XP with
+./qemu-system-i386 -device pci-ohci -device usb-tablet
+and then with
+./qemu-system-i386 -device pci-ohci -device usb-kbd
+
+and you will notice, that the usb keyboard is not detected. In fact, Windows XP detects the usb tablet and loads the driver for the tablet instead of the driver for the keyboard.
+
+The problem seems to be, that vendor and product ID and even the seriel of both the usb tablet and the usb keyboard are the same as an lsusb reveiles. Hence, Windows XP doesn't detect when you replace the tablet by a keyboard and vice versa. I didn't check other USB devices, but it seems a bad idea to me to have devices with the same vendor/product Id. I'm not aware, whether it is sufficient to change the seriel numbers of the devices.
+
+This is a problem with ancient Linux distributions that match vendor-product in Xorg.conf as well.
+
+This bug is more than 4 years old. Why did I even bother writing it? Is the problem still there in recent qemu versions?
+
+Hi Sven,
+  Hmm you do have a point - I wonder if this is fixed on windows by commit 5319dc7 from Gerd in November 2013 that added 'msos-desc' compat properties; but I see your point about having the same IDs
+
+(ccing in Gerd)
+
+Try "-device usb-tablet,serial=1234"
+
+I see no option in Xorg.conf to match serial. Maybe there is. It is mostly undocumented, especially for some random ancient X11 snapshot the distro has.
+
+That said the VM happens to be configured in such a way it works - keyboard and mouse are in same order on USB bus and in Xorg.conf
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/92
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1168 b/results/classifier/zero-shot/118/peripherals/1168
new file mode 100644
index 00000000..2a2d16f2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1168
@@ -0,0 +1,43 @@
+peripherals: 0.939
+graphic: 0.927
+arm: 0.861
+device: 0.838
+virtual: 0.805
+architecture: 0.784
+hypervisor: 0.769
+performance: 0.748
+network: 0.748
+debug: 0.747
+PID: 0.731
+semantic: 0.712
+user-level: 0.670
+x86: 0.626
+mistranslation: 0.615
+ppc: 0.610
+register: 0.550
+VMM: 0.544
+kernel: 0.534
+permissions: 0.533
+socket: 0.511
+files: 0.504
+KVM: 0.490
+vnc: 0.443
+risc-v: 0.415
+boot: 0.403
+assembly: 0.394
+TCG: 0.288
+i386: 0.032
+
+ivshmem: ivshmem-doorbell can't notify the MSI-X interrupt on Arm64 guest
+Description of problem:
+I init several qemu-kvm VMs on my arm64 host, which is a NVIDIA Xavier board. I want to use qemu's ivshmem-doorbell to build a sync shared memory communition with its MSI-X interrupt mechanism. I init the ivshmem-server and ivshmem-client on the host first, after then init the guests. The visul PCI-e device named "Inter-VM shared memory" can be successfully seen in my guests with command "lspci".
+I write a driver for this pci-e device to request and handle the MSI-X interrupts, which init well in the guest and can ring or receive from an interrupt vector on other peerID with the driver's IOCTL interface, the peer that receive vector in my environment is the ivshmem-client. However, when i use the ivshmem-client command "int" to ring my guest , the guest can't receive the msi-x interrupt notification.
+Steps to reproduce:
+1. init ivshmem-server on the host, with command "ivshmem-server -l 4M -M fg-doorbell -n 8 -F -v".
+2. init ivshmem-client on the host, with command "ivshmem-client -v".
+3. init the qemu-kvm VM .
+4. init the driver with "insmod" in guest to request the msi-x interrupt, while "cat /proc/interrupts" shows the interrupt request successfully!
+5. on host, ivshmem-client use command "int 1 0" to ring the guest's interrupt trigger, however ,nothing happened.
+Additional information:
+I am fully sure that there is no problem about the driver I wrote for the pci-e inter-VM shared memory device, for i has tested that the driver works on my X86 PC, where I deployed qemu-x86 VMs and the driver can work well in X86 guests with the inshmem-doorbell mechanism. The ivshmem-client work on host can notify the guest to trigger the correct msix-x interrupt. 
+Therefore, I digged the msi-x interrupt structure and use devmem tool to write the data to the messageAddress manually, which can correctly trigger the msi-x interrupt in my arm64 guest in the Xavier board, meaning the msi-x interrupt is OK in the guest. So I doubt maybe there is any issue on the ivshmem-doorbell mechanism that ring a interrupt vector in the guset of qemu-aarch64.
diff --git a/results/classifier/zero-shot/118/peripherals/1205156 b/results/classifier/zero-shot/118/peripherals/1205156
new file mode 100644
index 00000000..785ba37e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1205156
@@ -0,0 +1,280 @@
+peripherals: 0.866
+semantic: 0.859
+assembly: 0.850
+debug: 0.847
+performance: 0.844
+risc-v: 0.841
+PID: 0.831
+arm: 0.822
+architecture: 0.822
+graphic: 0.812
+virtual: 0.809
+hypervisor: 0.802
+mistranslation: 0.780
+socket: 0.774
+permissions: 0.766
+device: 0.763
+register: 0.762
+network: 0.754
+user-level: 0.751
+TCG: 0.750
+KVM: 0.750
+VMM: 0.750
+ppc: 0.742
+vnc: 0.735
+kernel: 0.722
+files: 0.701
+boot: 0.692
+x86: 0.692
+i386: 0.608
+
+Errors while compiling version 1.5.2
+
+Environment: Ubuntu 13.04
+
+"hw/ide/macio.c: In function ‘pmac_ide_atapi_transfer_cb’:
+hw/ide/macio.c:134:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+hw/ide/macio.c: In function ‘pmac_ide_transfer_cb’:
+hw/ide/macio.c:215:5: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int64_t’ [-Werror=format]
+hw/ide/macio.c:222:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+hw/ide/macio.c:264:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+cc1: all warnings being treated as errors
+make: *** [hw/ide/macio.o] Error 1"
+
+I got the source files with a "git clone git://git.qemu-project.org/qemu.git" + a recent "git fetch"
+
+I was able to compile and link latest 1.5.2 release with the tar.bz2 source files.
+
+I'm glad that ASAs do not crash anymore within GNS3 with this latest qemu release: nice work guys! :)
+
+Quoting Stefan Weil (2013-07-26 00:12:59)
+> Am 26.07.2013 04:03, schrieb jean-christophe manciot:
+> > Public bug reported:
+> >
+> > Environment: Ubuntu 13.04
+> >
+> > "hw/ide/macio.c: In function ‘pmac_ide_atapi_transfer_cb’:
+> > hw/ide/macio.c:134:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> > hw/ide/macio.c: In function ‘pmac_ide_transfer_cb’:
+> > hw/ide/macio.c:215:5: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int64_t’ [-Werror=format]
+> > hw/ide/macio.c:222:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> > hw/ide/macio.c:264:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> > cc1: all warnings being treated as errors
+> > make: *** [hw/ide/macio.o] Error 1"
+> >
+> > I got the source files with a "git clone git://git.qemu-
+> > project.org/qemu.git" + a recent "git fetch"
+> >
+> > ** Affects: qemu
+> >      Importance: Undecided
+> >          Status: New
+> >
+> 
+> 
+> 
+> This patch should fix it: http://patchwork.ozlabs.org/patch/258774/.
+> 
+> It's also still missing in git master, but was already applied to
+> qemu-trivial.
+
+This doesn't seem to be vanilla 1.5.2, where 04dd1259 isn't applicable
+(no MACIO_DPRINTF statements), but rather a newer release or past
+version with this patch on top:
+
+  commit 80fc95d8bdaf3392106b131a97ca701fd374489a
+  Author: Alexander Graf <email address hidden>
+  Date:   Fri Jun 28 13:30:01 2013 +0200
+  
+      PPC: dbdma: Support unaligned DMA access
+
+I'd pull them both in if Alex wants to send a backported version for
+1.5.2, but otherwise this doesn't seem to be an issue with stable.
+
+> 
+> Stefan
+
+
+Quoting Michael Roth (2013-08-12 20:05:32)
+> Quoting Stefan Weil (2013-07-26 00:12:59)
+> > Am 26.07.2013 04:03, schrieb jean-christophe manciot:
+> > > Public bug reported:
+> > >
+> > > Environment: Ubuntu 13.04
+> > >
+> > > "hw/ide/macio.c: In function ‘pmac_ide_atapi_transfer_cb’:
+> > > hw/ide/macio.c:134:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> > > hw/ide/macio.c: In function ‘pmac_ide_transfer_cb’:
+> > > hw/ide/macio.c:215:5: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int64_t’ [-Werror=format]
+> > > hw/ide/macio.c:222:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> > > hw/ide/macio.c:264:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> > > cc1: all warnings being treated as errors
+> > > make: *** [hw/ide/macio.o] Error 1"
+> > >
+> > > I got the source files with a "git clone git://git.qemu-
+> > > project.org/qemu.git" + a recent "git fetch"
+> > >
+> > > ** Affects: qemu
+> > >      Importance: Undecided
+> > >          Status: New
+> > >
+> > 
+> > 
+> > 
+> > This patch should fix it: http://patchwork.ozlabs.org/patch/258774/.
+> > 
+> > It's also still missing in git master, but was already applied to
+> > qemu-trivial.
+> 
+> This doesn't seem to be vanilla 1.5.2, where 04dd1259 isn't applicable
+> (no MACIO_DPRINTF statements), but rather a newer release or past
+> version with this patch on top:
+> 
+>   commit 80fc95d8bdaf3392106b131a97ca701fd374489a
+>   Author: Alexander Graf <email address hidden>
+>   Date:   Fri Jun 28 13:30:01 2013 +0200
+>   
+>       PPC: dbdma: Support unaligned DMA access
+> 
+> I'd pull them both in if Alex wants to send a backported version for
+> 1.5.2, but otherwise this doesn't seem to be an issue with stable.
+
+Forgot to cc Alex.
+
+> 
+> > 
+> > Stefan
+
+
+
+
+Am 13.08.2013 um 03:07 schrieb Michael Roth <email address hidden>:
+
+> Quoting Michael Roth (2013-08-12 20:05:32)
+>> Quoting Stefan Weil (2013-07-26 00:12:59)
+>>> Am 26.07.2013 04:03, schrieb jean-christophe manciot:
+>>>> Public bug reported:
+>>>> 
+>>>> Environment: Ubuntu 13.04
+>>>> 
+>>>> "hw/ide/macio.c: In function ‘pmac_ide_atapi_transfer_cb’:
+>>>> hw/ide/macio.c:134:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+>>>> hw/ide/macio.c: In function ‘pmac_ide_transfer_cb’:
+>>>> hw/ide/macio.c:215:5: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int64_t’ [-Werror=format]
+>>>> hw/ide/macio.c:222:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+>>>> hw/ide/macio.c:264:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+>>>> cc1: all warnings being treated as errors
+>>>> make: *** [hw/ide/macio.o] Error 1"
+>>>> 
+>>>> I got the source files with a "git clone git://git.qemu-
+>>>> project.org/qemu.git" + a recent "git fetch"
+>>>> 
+>>>> ** Affects: qemu
+>>>>     Importance: Undecided
+>>>>         Status: New
+>>> 
+>>> 
+>>> 
+>>> This patch should fix it: http://patchwork.ozlabs.org/patch/258774/.
+>>> 
+>>> It's also still missing in git master, but was already applied to
+>>> qemu-trivial.
+>> 
+>> This doesn't seem to be vanilla 1.5.2, where 04dd1259 isn't applicable
+>> (no MACIO_DPRINTF statements), but rather a newer release or past
+>> version with this patch on top:
+>> 
+>>  commit 80fc95d8bdaf3392106b131a97ca701fd374489a
+>>  Author: Alexander Graf <email address hidden>
+>>  Date:   Fri Jun 28 13:30:01 2013 +0200
+>> 
+>>      PPC: dbdma: Support unaligned DMA access
+>> 
+>> I'd pull them both in if Alex wants to send a backported version for
+>> 1.5.2, but otherwise this doesn't seem to be an issue with stable.
+> 
+> Forgot to cc Alex.
+
+I'd rather not backport these to 1.5, as the patches only make sense as a whole with an OpenBIOS update.
+
+IIUC the compile error has been fixed for 1.6, correct?
+
+
+Alex
+
+> 
+>> 
+>>> 
+>>> Stefan
+
+
+Quoting Alexander Graf (2013-08-12 23:06:19)
+> Am 13.08.2013 um 03:07 schrieb Michael Roth <email address hidden>:
+> 
+> > Quoting Michael Roth (2013-08-12 20:05:32)
+> >> Quoting Stefan Weil (2013-07-26 00:12:59)
+> >>> Am 26.07.2013 04:03, schrieb jean-christophe manciot:
+> >>>> Public bug reported:
+> >>>> 
+> >>>> Environment: Ubuntu 13.04
+> >>>> 
+> >>>> "hw/ide/macio.c: In function ‘pmac_ide_atapi_transfer_cb’:
+> >>>> hw/ide/macio.c:134:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> >>>> hw/ide/macio.c: In function ‘pmac_ide_transfer_cb’:
+> >>>> hw/ide/macio.c:215:5: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int64_t’ [-Werror=format]
+> >>>> hw/ide/macio.c:222:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> >>>> hw/ide/macio.c:264:9: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘hwaddr’ [-Werror=format]
+> >>>> cc1: all warnings being treated as errors
+> >>>> make: *** [hw/ide/macio.o] Error 1"
+> >>>> 
+> >>>> I got the source files with a "git clone git://git.qemu-
+> >>>> project.org/qemu.git" + a recent "git fetch"
+> >>>> 
+> >>>> ** Affects: qemu
+> >>>>     Importance: Undecided
+> >>>>         Status: New
+> >>> 
+> >>> 
+> >>> 
+> >>> This patch should fix it: http://patchwork.ozlabs.org/patch/258774/.
+> >>> 
+> >>> It's also still missing in git master, but was already applied to
+> >>> qemu-trivial.
+> >> 
+> >> This doesn't seem to be vanilla 1.5.2, where 04dd1259 isn't applicable
+> >> (no MACIO_DPRINTF statements), but rather a newer release or past
+> >> version with this patch on top:
+> >> 
+> >>  commit 80fc95d8bdaf3392106b131a97ca701fd374489a
+> >>  Author: Alexander Graf <email address hidden>
+> >>  Date:   Fri Jun 28 13:30:01 2013 +0200
+> >> 
+> >>      PPC: dbdma: Support unaligned DMA access
+> >> 
+> >> I'd pull them both in if Alex wants to send a backported version for
+> >> 1.5.2, but otherwise this doesn't seem to be an issue with stable.
+> > 
+> > Forgot to cc Alex.
+> 
+> I'd rather not backport these to 1.5, as the patches only make sense as a whole with an OpenBIOS update.
+
+Ok, makes sense, just thought I'd double-check. Got the impression from the bug
+report that maybe some downstreams were carrying your patch on top of 1.5.2 for
+OSX support, but I'm not really sure what's going on here.
+
+> 
+> IIUC the compile error has been fixed for 1.6, correct?
+
+Yup, should be fixed upstream with 04dd1259
+
+> 
+> 
+> Alex
+> 
+> > 
+> >> 
+> >>> 
+> >>> Stefan
+
+
+Marking this ticket as "Fix released" according to comment #6.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1219207 b/results/classifier/zero-shot/118/peripherals/1219207
new file mode 100644
index 00000000..c5657e37
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1219207
@@ -0,0 +1,92 @@
+peripherals: 0.894
+user-level: 0.849
+hypervisor: 0.837
+permissions: 0.836
+VMM: 0.832
+vnc: 0.829
+KVM: 0.822
+ppc: 0.815
+debug: 0.813
+risc-v: 0.798
+TCG: 0.793
+x86: 0.779
+graphic: 0.773
+i386: 0.771
+device: 0.762
+register: 0.762
+performance: 0.756
+architecture: 0.754
+semantic: 0.736
+virtual: 0.736
+mistranslation: 0.701
+files: 0.697
+socket: 0.696
+arm: 0.691
+assembly: 0.685
+network: 0.681
+boot: 0.660
+PID: 0.647
+kernel: 0.598
+
+QMP (32 bit only) segfaults in query-tpm-types when compiled with --enable-tpm
+
+NB: This bug ONLY happens on i686.  When qemu is compiled for x86-64, the bug does NOT happen.
+
+$ ./configure --enable-tpm
+$ make
+$ (sleep 5; printf '{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') | ./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 6, "major": 1}, "package": ""}, "capabilities": []}}
+{"return": {}}
+Segmentation fault (core dumped)
+
+The stack trace is:
+
+#0  output_type_enum (v=0xb9938228, obj=0x5, 
+    strings=0xb77f0320 <TpmType_lookup>, kind=0xb767f1d4 "TpmType", name=0x0, 
+    errp=0xbfec4628) at qapi/qapi-visit-core.c:306
+#1  0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5, 
+    strings=0xb77f0320 <TpmType_lookup>, kind=kind@entry=0xb767f1d4 "TpmType", 
+    name=name@entry=0x0, errp=errp@entry=0xbfec4628)
+    at qapi/qapi-visit-core.c:114
+#2  0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0, 
+    obj=<optimized out>, m=0xb9938228) at qapi-visit.c:5220
+#3  visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678, 
+    name=name@entry=0xb76545a6 "unused", errp=errp@entry=0xbfec4674)
+    at qapi-visit.c:5206
+#4  0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674, 
+    ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795
+#5  qmp_marshal_input_query_tpm_types (mon=0xb9937098, qdict=0xb99379a0, 
+    ret=0xbfec46d8) at qmp-marshal.c:3817
+#6  0xb7581d7a in qmp_call_cmd (cmd=<optimized out>, params=0xb99379a0, 
+    mon=0xb9937098) at /home/rjones/d/qemu/monitor.c:4644
+#7  handle_qmp_command (parser=0xb99370ec, tokens=0xb9941438)
+    at /home/rjones/d/qemu/monitor.c:4710
+#8  0xb7631d8f in json_message_process_token (lexer=0xb99370f0, 
+    token=0xb993f3a8, type=JSON_OPERATOR, x=29, y=1)
+    at qobject/json-streamer.c:87
+#9  0xb764579b in json_lexer_feed_char (lexer=lexer@entry=0xb99370f0, 
+    ch=<optimized out>, flush=flush@entry=false) at qobject/json-lexer.c:303
+#10 0xb76458c8 in json_lexer_feed (lexer=lexer@entry=0xb99370f0, 
+    buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1)
+    at qobject/json-lexer.c:356
+#11 0xb7631fab in json_message_parser_feed (parser=0xb99370ec, 
+    buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1)
+    at qobject/json-streamer.c:110
+#12 0xb75803eb in monitor_control_read (opaque=0xb9937098, 
+    buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", size=1) at /home/rjones/d/qemu/monitor.c:4731
+#13 0xb74b191e in qemu_chr_be_write (len=<optimized out>, 
+    buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267 \367b\267\315\372\223\271\065\023j\267\002", s=0xb9935800) at qemu-char.c:165
+#14 fd_chr_read (chan=0xb9935870, cond=(G_IO_IN | G_IO_HUP), opaque=0xb9935800)
+    at qemu-char.c:841
+#15 0xb71f6876 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
+#16 0xb71b0286 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
+#17 0xb747a13e in glib_pollfds_poll () at main-loop.c:189
+#18 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:234
+#19 main_loop_wait (nonblocking=1) at main-loop.c:484
+#20 0xb7309f11 in main_loop () at vl.c:2090
+#21 main (argc=8, argv=0xbfec5c14, envp=0xbfec5c38) at vl.c:4435
+
+Looks like the fix has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=02dc4bf5684d3fb46786
+... so closing this ticket now.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1245703 b/results/classifier/zero-shot/118/peripherals/1245703
new file mode 100644
index 00000000..047e08ba
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1245703
@@ -0,0 +1,108 @@
+peripherals: 0.808
+risc-v: 0.808
+mistranslation: 0.799
+graphic: 0.799
+VMM: 0.793
+user-level: 0.778
+performance: 0.771
+permissions: 0.769
+architecture: 0.768
+device: 0.766
+TCG: 0.750
+files: 0.748
+register: 0.739
+PID: 0.739
+vnc: 0.738
+kernel: 0.733
+network: 0.730
+semantic: 0.729
+arm: 0.726
+debug: 0.726
+socket: 0.725
+KVM: 0.704
+assembly: 0.702
+hypervisor: 0.701
+ppc: 0.688
+x86: 0.670
+boot: 0.668
+virtual: 0.662
+i386: 0.529
+
+LD_PREFIX option reads directories recursively in an endless loop
+
+If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel.
+
+According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop.
+
+The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. 
+
+Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time.
+
+On 28 October 2013 23:15, Sebastian Macke <email address hidden> wrote:
+> If I run qemu user emulation with -L /path/to/my/sysroot/ in which also
+> the proc and dev filesystem is mounted QEMU eats my memory until it gets
+> killed by the kernel.
+>
+> According to the strace output it follows the symbolic links in the proc
+> filesystem running forever in a recursive loop.
+>
+> The easiest solution would be to add in the function "add_dir_maybe" in
+> the file util/path.c an additional check for symbolic links that it
+> don't follow them.
+
+Yeah, this -L code is just busted. It's really only intended to work
+with extremely simple sysroot directories which don't have weird
+stuff like proc mounts or symlinks and aren't very big.
+
+If the thing you're looking at isn't like that then you might be better
+off using the "static qemu and chroot into the directory" approach
+instead.
+
+-- PMM
+
+
+Ok, thanks for the info.
+For me it looks like removing the whole path code and putting a one-liner combining two string is the best solution. But maybe I am missing something.
+
+qemu-arm *and* qemu-arm-static 1.5.0+dfsg-3ubuntu5.1 (AMD64 13.10 host) are affected by this.
+
+Steps to reproduce:
+0. mkdir /mnt/mychroot
+1. qemu-debootstrap --arch=armhf wheezy /mnt/mychroot http://ftp.debian.org/debian
+2. qemu-arm-static -L /mnt/mychroot /mnt/mychroot/usr/sbin/chroot /mnt/mychroot /bin/sh
+
+In this case, the loop starts when it meets /mnt/mychroot/dev/fd (which links to /proc/self/fd).
+
+One ugly workaround is, in case anyone needs it:
+
+cp -a /usr/bin/qemu-arm-static /mnt/mychroot/
+chroot /mnt/mychroot /qemu-arm-static /bin/sh
+
+We're (Yocto Project) hit this often.  We're building a root file system and then using userspace qemu to run binaries inside it (such as fc-cache).  If a cyclic symlink appears in the rootfs, it blows up.
+
+
+
+On 26 March 2015 at 21:37, Ross Burton <email address hidden> wrote:
+> We're (Yocto Project) hit this often.  We're building a root file system
+> and then using userspace qemu to run binaries inside it (such as fc-
+> cache).  If a cyclic symlink appears in the rootfs, it blows up.
+
+If you're actually building a rootfs then you're probably
+better off using binfmt-misc and chrooting into it rather
+than using -L. -L really isn't intended to point at a
+full rootfs.
+
+-- PMM
+
+
+We need to be able to run qemu as not root.  Has anyone tried using qemu with fakechroot?
+
+I posted a patch a while back that would fix this:
+
+https://patchwork.kernel.org/patch/9512083/
+
+Fixed by in 4.1.0 by:
+
+f3a8bdc1d5b2 ("util/path: Do not cache all filenames at startup")
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1250 b/results/classifier/zero-shot/118/peripherals/1250
new file mode 100644
index 00000000..4f5fba50
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1250
@@ -0,0 +1,33 @@
+peripherals: 0.962
+device: 0.806
+arm: 0.738
+register: 0.571
+performance: 0.552
+permissions: 0.425
+boot: 0.416
+files: 0.415
+graphic: 0.382
+mistranslation: 0.256
+debug: 0.246
+semantic: 0.243
+socket: 0.238
+network: 0.237
+risc-v: 0.211
+architecture: 0.181
+ppc: 0.179
+TCG: 0.154
+vnc: 0.122
+KVM: 0.114
+hypervisor: 0.104
+i386: 0.102
+VMM: 0.101
+virtual: 0.098
+user-level: 0.094
+PID: 0.061
+assembly: 0.055
+x86: 0.055
+kernel: 0.054
+
+[RFE] on windows, attach any storport disk directly, not just physicaldrives
+Additional information:
+
diff --git a/results/classifier/zero-shot/118/peripherals/126 b/results/classifier/zero-shot/118/peripherals/126
new file mode 100644
index 00000000..27481352
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/126
@@ -0,0 +1,31 @@
+peripherals: 0.954
+device: 0.794
+performance: 0.682
+mistranslation: 0.582
+graphic: 0.484
+semantic: 0.400
+VMM: 0.366
+virtual: 0.270
+debug: 0.265
+user-level: 0.186
+ppc: 0.168
+PID: 0.109
+architecture: 0.108
+network: 0.107
+permissions: 0.107
+arm: 0.103
+boot: 0.099
+register: 0.094
+i386: 0.065
+vnc: 0.053
+TCG: 0.052
+hypervisor: 0.042
+assembly: 0.027
+KVM: 0.017
+x86: 0.016
+risc-v: 0.013
+socket: 0.008
+files: 0.008
+kernel: 0.006
+
+qemu-input: Mouse stops working in Windows guest
diff --git a/results/classifier/zero-shot/118/peripherals/1311614 b/results/classifier/zero-shot/118/peripherals/1311614
new file mode 100644
index 00000000..9bc02813
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1311614
@@ -0,0 +1,152 @@
+peripherals: 0.909
+user-level: 0.908
+mistranslation: 0.906
+device: 0.901
+register: 0.899
+virtual: 0.891
+ppc: 0.839
+permissions: 0.839
+architecture: 0.836
+risc-v: 0.835
+vnc: 0.832
+debug: 0.826
+network: 0.805
+PID: 0.801
+semantic: 0.797
+assembly: 0.796
+graphic: 0.789
+performance: 0.782
+arm: 0.778
+kernel: 0.776
+socket: 0.770
+files: 0.766
+hypervisor: 0.760
+VMM: 0.747
+KVM: 0.743
+i386: 0.733
+TCG: 0.721
+boot: 0.682
+x86: 0.656
+
+qemu-arm segfaults with gcc 4.9.0
+
+I have an ARM chroot that working with qemu-arm emulation
+
+[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm
+enabled
+interpreter /usr/bin/qemu-arm-binfmt
+flags: P
+offset 0
+magic 7f454c4601010100000000000000000002002800
+mask ffffffffffffff00fffffffffffffffffeffffff
+
+
+In chroot installed gcc dependencies with 4.9.0 version
+
+sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0
+
+libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl
+libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl
+libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl
+libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl
+
+
+When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message
+
+
+example:
+
+[root@filzbach /]# uname -a
+Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux
+
+[root@filzbach /]# rpm
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+
+Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0.
+
+When i downgrade it to 4.8.3 all working fine again.
+It looks like a qemu bug with gcc.
+
+
+P.S.
+I tried to rebuild qemu with gcc 4.9.0
+I tried to build qemu from git sources, from fedora sources, from suse sources etc.
+
+And of course i rebuilt rpm package with latest gcc 4.9.0
+Btw all working fine on a real hardware.
+
+Bump
+
+A backtrace of where the crash is in QEMU might be interesting.
+
+Do you have any howto to  produce backtrace?
+
+I debugged it originally but did only suggest a temporary workaround...
+The crash, not really in qemu, looks like this:
+
+--%<--
+Remote debugging using localhost:1235
+Reading symbols from
+/home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3...Reading
+symbols from
+/home2/fedya/openmandriva/home/fedya/root/usr/lib/debug/lib/ld-2.19.so.debug...done.
+done.
+Loaded symbols for /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3
+0xf67dfd00 in _start ()
+   from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3
+(gdb) c
+Continuing.
+
+Program received signal SIGSEGV, Segmentation fault.
+memset () at ../ports/sysdeps/arm/memset.S:53
+53              sfi_breg r3, \
+(gdb) bt
+#0  memset () at ../ports/sysdeps/arm/memset.S:53
+#1  0xf650b5da in __pthread_getaffinity_new (th=th@entry=4123619328, cpusetsize=4,
+    cpuset=0xf008) at ../nptl/sysdeps/unix/sysv/linux/pthread_getaffinity.c:41
+#2  0xf60ca6d8 in gomp_init_num_threads () at
+../../../libgomp/config/linux/proc.c:93
+#3  0xf60c28b2 in initialize_env () at ../../../libgomp/env.c:1187
+#4  0xf67ea514 in call_init (env=<optimized out>, argv=<optimized out>,
+    argc=<optimized out>, l=<optimized out>) at dl-init.c:76
+#5  _dl_init (main_map=0xf67fe908, argc=1, argv=0xf6ffecf4, env=0xf6ffecfc)
+    at dl-init.c:124
+#6  0xf67dfd32 in _dl_start_user ()
+   from /home/fedya/openmandriva/home/fedya/root/lib/ld-linux-armhf.so.3
+Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+(gdb) q
+A debugging session is active.
+
+        Inferior 1 [Remote target] will be killed.
+
+Quit anyway? (y or n) y
+--%<--
+
+My suggestion was to report problems upstream ofcourse, and
+a temporary quick fix would be to replace libgomp from the one
+from gcc 4.8x or replace the body of gomp_init_num_threads
+from gcc-4.9.0/libgomp/config/linux/proc.c with the one from
+gcc-4.8.2/libgomp/config/linux/proc.c
+
+I believe gcc 4.9 is too smart, and some stub is missing somewhere,
+e.g. in the arm chroot checking /proc/cpuinfo shows x86_64 cpus.
+
+
+Hmm, getaffinity? Can you try applying this qemu patch:
+https://patches.linaro.org/30259/
+
+and see if it resolves the problem?
+
+
+Will do!
+Thanks
+
+Fixed, thanks
+
+Fixed by commit be3bd286bc06 back in 2014.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1357226 b/results/classifier/zero-shot/118/peripherals/1357226
new file mode 100644
index 00000000..0a76fe17
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1357226
@@ -0,0 +1,97 @@
+peripherals: 0.843
+architecture: 0.841
+register: 0.825
+graphic: 0.819
+TCG: 0.815
+boot: 0.807
+mistranslation: 0.785
+debug: 0.774
+device: 0.772
+permissions: 0.766
+semantic: 0.766
+performance: 0.765
+virtual: 0.745
+risc-v: 0.743
+user-level: 0.737
+PID: 0.731
+vnc: 0.726
+arm: 0.716
+files: 0.705
+VMM: 0.689
+socket: 0.684
+KVM: 0.677
+ppc: 0.670
+hypervisor: 0.663
+assembly: 0.661
+kernel: 0.650
+x86: 0.600
+network: 0.538
+i386: 0.441
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+steps to reproduce:
+pbuilder-dist utopic armhf create
+pbuilder-dist utopic armhf login
+apt-get install imagemagick
+convert foo.xpm foo.png
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+(doesn't matter if images are actually there or not)
+
+I'm running into this same problem, and it's making automation of Raspberry Pi builds of my application difficult.
+
+I'm running in a chroot environment:
+3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 armv7l GNU/Linux
+
+Package: qemu
+Version: 1.1.2+dfsg-6a+deb7u11
+
+This may or may not be relevant here, but the mysterious "uncaught target signal 11" error was fixed for maas images (lp:maas-images) build process by increasing the memory to the VMs that were doing the build.  We had been doing the cross/qemu-static building in ~512M vms and that was resulting in somewhat transient failures during 'apt-get update'.  Upping the memory of the vm to 2G made those go away.
+
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Thanks Thomas for assigning to Ubuntu's Qemu which is correct in this case.
+I know there are still issues reported by Locutus to look into, but this one seems expired.
+
+I don't want to appear randomly closing bugs, so I verified with something "old" which today would be Trusty. So there I ran.
+
+$ pbuilder-dist trusty armhf create
+$ pbuilder-dist trusty armhf login
+$ apt-get install imagemagick
+$ convert foo.xpm foo.png (file not there)
+$ convert ./share/pixmaps/display.im6.xpm ./share/pixmaps/display.im6.png (Trusty)
+$ convert ./share/pixmaps/display-im6.q16.xpm ./share/pixmaps/display-im6.q16.png (Artful)
+
+All working, so closing this old bug as invalid now.
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Hi, I am getting the error:
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+When I try to execute a Hello World binary on my amd64 machine, with Hello World built by mips-linux-gnu-g++, using either mips binfmt extensions (./hello) or qemu-mips-static hello. I have libstdc++6:mips installed as well. My source code is as follows:
+
+#include <iostream>
+using std::cout;
+
+int main() {
+    cout << "Hello World!\n";
+    return 0;
+}
+
+Worth noting that this problem only happens with mips cross runs. mips64el and mipsel work just fine.
+
+I happen to be doing this in Debian 10.0.0 Buster stable amd64 on VirtualBox on Ubuntu 19.04 Disco Dingo amd64, but it looks like the same behavior on native Ubuntu hosts as well. I tried increasing guest RAM to 1GiB and 2GiB, with no affect on the runtime error message. Is there a glitch in one of the mips packages?
+
+@mcandre, I think your issue, even though it's also a segfault, is a different one than this bug from 2014, which was about armhf and was verified in comment #4 as no longer happening.
+
+Could you please open a separate bug about what you experienced, including detailed steps to reproduce it? Attaching the core file would also help.
+
+Thanks!
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/136 b/results/classifier/zero-shot/118/peripherals/136
new file mode 100644
index 00000000..b958c105
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/136
@@ -0,0 +1,31 @@
+peripherals: 0.950
+mistranslation: 0.788
+device: 0.769
+graphic: 0.753
+permissions: 0.687
+virtual: 0.676
+performance: 0.608
+semantic: 0.431
+network: 0.421
+arm: 0.365
+hypervisor: 0.360
+ppc: 0.339
+architecture: 0.335
+vnc: 0.204
+debug: 0.165
+user-level: 0.158
+i386: 0.158
+risc-v: 0.113
+boot: 0.112
+register: 0.098
+VMM: 0.090
+x86: 0.076
+TCG: 0.050
+files: 0.046
+kernel: 0.045
+PID: 0.045
+socket: 0.042
+assembly: 0.030
+KVM: 0.021
+
+windows qemu-img create vpc/vhdx error
diff --git a/results/classifier/zero-shot/118/peripherals/1381879 b/results/classifier/zero-shot/118/peripherals/1381879
new file mode 100644
index 00000000..27e9f780
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1381879
@@ -0,0 +1,68 @@
+peripherals: 0.882
+virtual: 0.861
+graphic: 0.854
+mistranslation: 0.805
+device: 0.793
+x86: 0.771
+hypervisor: 0.733
+socket: 0.723
+architecture: 0.719
+KVM: 0.691
+performance: 0.684
+network: 0.674
+user-level: 0.671
+PID: 0.640
+debug: 0.638
+VMM: 0.621
+kernel: 0.539
+register: 0.533
+files: 0.529
+ppc: 0.525
+permissions: 0.521
+assembly: 0.428
+risc-v: 0.410
+semantic: 0.388
+vnc: 0.386
+TCG: 0.378
+boot: 0.326
+arm: 0.280
+i386: 0.211
+
+can not run vm with a serial port
+
+environment:
+server: centOS 6.5, 3.14.19, x86_64
+qemu-kvm: QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard
+qemu-system-x86_64 :QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard
+virt-manager: 0.9.0
+
+VM: centOS 6.5, 3.12.30, x86_64
+
+reproduce step:
+1. add serial device
+2. select device type: unix socket
+                 device parameters: path=/dev/ttyS0
+                                                       mode=client mode(connect)
+3. run the VM
+
+phenomenon:
+Error starting domain: internal error process exited while connecting to monitor: qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: socket bind failed: Address already in use
+qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: chardev: opening backend "socket" failed
+
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb
+    callback(*args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup
+    self._backend.create()
+  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 678, in create
+    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
+libvirtError: internal error process exited while connecting to monitor: qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: socket bind failed: Address already in use
+qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: chardev: opening backend "socket" failed
+
+Opening a socket with the name of a device file can not work, you've got to specify a different name for a unix socket instead. So this is not a bug.
+
+(or if you just wanted to complain about the rather ugly traceback instead of a nice error message: Please file a bug against virt-manager instead. Thanks!)
+
diff --git a/results/classifier/zero-shot/118/peripherals/1410288 b/results/classifier/zero-shot/118/peripherals/1410288
new file mode 100644
index 00000000..a05a70ee
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1410288
@@ -0,0 +1,96 @@
+peripherals: 0.909
+socket: 0.886
+permissions: 0.874
+hypervisor: 0.856
+device: 0.849
+graphic: 0.830
+debug: 0.829
+PID: 0.821
+assembly: 0.810
+files: 0.807
+boot: 0.798
+register: 0.777
+semantic: 0.777
+user-level: 0.766
+network: 0.759
+architecture: 0.757
+arm: 0.740
+virtual: 0.728
+i386: 0.721
+performance: 0.721
+risc-v: 0.702
+kernel: 0.701
+TCG: 0.689
+mistranslation: 0.660
+x86: 0.645
+vnc: 0.623
+ppc: 0.601
+VMM: 0.573
+KVM: 0.534
+
+qemu-img conversion to qcow2 hangs with blank image less than 100kiB
+
+If you try to convert a blank image to qcow2 that is less than 100kiB in size then qemu-img hangs trying to seek to the end of the file. 
+
+$ truncate --size 102399 /tmp/temp
+$ qemu-img convert -p -O qcow2 /tmp/temp /tmp/temp2.qcow2
+
+I'm finding this on all versions of qemu-img v2.
+
+strace shows a seek loop.
+
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+
+ProblemType: Bug
+DistroRelease: Ubuntu 14.04
+Package: qemu-utils 2.0.0+dfsg-2ubuntu1.10
+ProcVersionSignature: User Name 3.13.0-43.72-generic 3.13.11.11
+Uname: Linux 3.13.0-43-generic i686
+ApportVersion: 2.14.1-0ubuntu3.6
+Architecture: i386
+Date: Tue Jan 13 14:30:39 2015
+SourcePackage: qemu
+UpgradeStatus: No upgrade log present (probably fresh install)
+
+
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Workaround is to 'fallocate'. Problem seems to be linked to files with sparse holes in them. 
+
+
+
+verified this fails as described on vivid:
+$ dpkg-query --show qemu-utils
+qemu-utils	1:2.1+dfsg-11ubuntu1
+
+and also on trusty.
+
+$ dpkg-query --show qemu-utils
+qemu-utils	2.0.0+dfsg-2ubuntu1.10
+
+
+Does it also fail with the qemu from
+https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream ?
+(This isn't quite git head, but it is qemu v2.2)
+
+
+Went ahead and tested - it is in fact fixed in the v2.2 version.
+
+qemu is 2.5 in 16.04 and 2.6.1 in Zesty, so this is presumably Fix Released now. If incorrect, please explain and reopen.
+
diff --git a/results/classifier/zero-shot/118/peripherals/144 b/results/classifier/zero-shot/118/peripherals/144
new file mode 100644
index 00000000..bcbf76cf
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/144
@@ -0,0 +1,31 @@
+peripherals: 0.950
+device: 0.823
+architecture: 0.662
+performance: 0.572
+arm: 0.515
+boot: 0.463
+network: 0.416
+socket: 0.383
+graphic: 0.373
+semantic: 0.345
+ppc: 0.250
+risc-v: 0.235
+mistranslation: 0.185
+register: 0.180
+debug: 0.172
+vnc: 0.163
+user-level: 0.155
+TCG: 0.149
+PID: 0.132
+permissions: 0.124
+hypervisor: 0.095
+VMM: 0.086
+virtual: 0.085
+assembly: 0.054
+kernel: 0.021
+files: 0.015
+x86: 0.010
+i386: 0.009
+KVM: 0.007
+
+Passthrough USB Host Keyboard doesn't work on Q35 platform on boot-up
diff --git a/results/classifier/zero-shot/118/peripherals/1444 b/results/classifier/zero-shot/118/peripherals/1444
new file mode 100644
index 00000000..3f946be1
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1444
@@ -0,0 +1,72 @@
+peripherals: 0.814
+permissions: 0.812
+ppc: 0.792
+risc-v: 0.784
+hypervisor: 0.782
+mistranslation: 0.781
+performance: 0.779
+user-level: 0.779
+architecture: 0.776
+virtual: 0.771
+debug: 0.758
+TCG: 0.749
+graphic: 0.749
+register: 0.731
+device: 0.730
+VMM: 0.729
+semantic: 0.714
+vnc: 0.711
+arm: 0.693
+KVM: 0.687
+boot: 0.672
+PID: 0.671
+files: 0.649
+socket: 0.645
+x86: 0.624
+assembly: 0.611
+network: 0.601
+i386: 0.573
+kernel: 0.555
+
+ld.so on aarch64 crashes (SIGSEGV) qemu-aarch64-static to verify attached executable
+Description of problem:
+I'm currently managing an automation to build a linux distribution from nothing.
+The issues is when I try to cross compile gobject-introspection for aarch64 (it is currently working on arm) because the g-ir-compile phase requires a binary verification using ld-linux-aarch64-so-1 --verify GLib-2.0 process used by ldd, that crashes qemu-aarch64-static.
+Original command is: ${SYSROOT}/lib/ld-linux-aarch64-so-1 --verify ${HOME}/builds/gobject-introspection_1.75.4/tmp-introspectnpyrhpje/GLib-2.0.
+I simplified the problem bringing out the ld.so and GLib-2.0 binary to obtain the same result.
+
+This happens with glibc 2.35 and glibc 2.36 on aarch64 built with a gcc-12.2 cross compiler (x86 -> aarch64).
+
+[GLib-2.0](/uploads/47932b18278835fb13ef0de4c34872fa/GLib-2.0)
+
+[ld-linux-aarch64.so.1](/uploads/0ee01949285bea8ccfcebdc88a1d5b33/ld-linux-aarch64.so.1)
+
+I tried to debug the SIGSEGV but it's out completely out of my capacity.
+Steps to reproduce:
+1. Copy the 2 attached files in a directory:
+2. Run: qemu-aarch64-static ./ld-linux-aarch64.so.1 --verify ./GLib-2.0
+3. Result: Segmentation fault.
+Additional information:
+I attach the output of gdb after install qemu debug symbols:
+
+```
+Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault.
+0x0000000000401088 in ?? ()
+(gdb) bt
+#0  0x0000000000401088 in ?? ()
+#1  0x00000000006aa439 in g_malloc0 ()
+#2  0x000000000061bb4b in page_find_alloc (index=index@entry=1024, alloc=alloc@entry=1)
+    at ../accel/tcg/translate-all.c:494
+#3  0x000000000061db12 in page_set_flags (start=start@entry=4194304, end=end@entry=4206592, flags=9, flags@entry=73)
+    at ../accel/tcg/translate-all.c:2288
+#4  0x0000000000629f10 in target_mmap (start=<optimized out>, start@entry=4194304, len=<optimized out>,
+    len@entry=12288, target_prot=target_prot@entry=1, flags=2066, fd=fd@entry=3, offset=offset@entry=0)
+    at ../linux-user/mmap.c:629
+#5  0x0000000000641e1d in do_syscall1 (cpu_env=0x9e8c10, num=222, arg1=4194304, arg2=12288, arg3=1,
+    arg4=<optimized out>, arg5=3, arg6=0, arg8=<optimized out>, arg7=<optimized out>) at ../linux-user/syscall.c:9961
+#6  0x0000000000644c8c in do_syscall (cpu_env=cpu_env@entry=0x9e8c10, num=222, arg1=4194304, arg2=12288, arg3=1,
+    arg4=2066, arg5=3, arg6=0, arg7=0, arg8=0) at ../linux-user/syscall.c:13203
+#7  0x000000000040fca8 in cpu_loop (env=env@entry=0x9e8c10) at ../linux-user/aarch64/cpu_loop.c:93
+#8  0x000000000040267f in main (argc=<optimized out>, argv=0x7fffffffdfc8, envp=<optimized out>)
+    at ../linux-user/main.c:897
+```
diff --git a/results/classifier/zero-shot/118/peripherals/1496384 b/results/classifier/zero-shot/118/peripherals/1496384
new file mode 100644
index 00000000..b431d324
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1496384
@@ -0,0 +1,52 @@
+peripherals: 0.813
+x86: 0.756
+device: 0.718
+boot: 0.700
+architecture: 0.671
+socket: 0.579
+semantic: 0.575
+graphic: 0.475
+ppc: 0.460
+performance: 0.415
+register: 0.411
+PID: 0.408
+kernel: 0.387
+permissions: 0.376
+network: 0.369
+user-level: 0.335
+files: 0.330
+assembly: 0.311
+VMM: 0.307
+hypervisor: 0.275
+risc-v: 0.271
+debug: 0.268
+vnc: 0.257
+mistranslation: 0.255
+TCG: 0.225
+virtual: 0.225
+arm: 0.208
+i386: 0.127
+KVM: 0.050
+
+Error 0x5D in Qemu for Windows 
+
+The reason to use qemu for Windows is that the mouse in emulated Windows works well while it is unusable in  qemu at Ubuntu. 
+Alternative solution/bug is mouse usability in qemu for Linux.
+Well-known issue of error 0x5D when booting Win 7 x64 on qemu without kvm, marked as resolved at Linux.
+
+Used qemu for Windows downloaded from http://qemu.weilnetz.de/
+Tested on  qemu 2.3.94 64-bit and  qemu 2.4.0 32-bit.
+
+Options :
+qemu-system-x86_64.exe  -m 1536 -cpu qemu64,+nx,+pae,+mce,+cx8,+apic,+sep,+mtrr,+pge,+mca,+cmov,+pat,+pse36,+clflush,+acpi,+mmx,+fxsr,+sse,+sse2,+ss,+fxsr,+sse,+sse2,+ss,+de,+mtrr,+mca,+clflush
+ win_7_work.qcow2
+
+On qemu at Ubuntu with kvm Win7 x64 works ,but mouse is unusable as mentioned above.
+
+A solution is to convert from vmdk to qcow2 and back working in VmWare with Windows images. Repeated  Windows activation could be needed.
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Have you tried "-usb -device usb-tablet" already?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1504 b/results/classifier/zero-shot/118/peripherals/1504
new file mode 100644
index 00000000..f607efda
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1504
@@ -0,0 +1,31 @@
+peripherals: 0.966
+device: 0.892
+network: 0.865
+architecture: 0.859
+performance: 0.606
+boot: 0.536
+assembly: 0.518
+files: 0.472
+graphic: 0.412
+ppc: 0.372
+arm: 0.360
+vnc: 0.339
+permissions: 0.337
+debug: 0.278
+semantic: 0.257
+register: 0.204
+virtual: 0.202
+risc-v: 0.198
+hypervisor: 0.195
+x86: 0.184
+socket: 0.173
+i386: 0.169
+mistranslation: 0.165
+VMM: 0.128
+user-level: 0.126
+TCG: 0.099
+kernel: 0.080
+PID: 0.054
+KVM: 0.012
+
+Implement Synopsys DesignWare PCI-I2C adapter model
diff --git a/results/classifier/zero-shot/118/peripherals/1532 b/results/classifier/zero-shot/118/peripherals/1532
new file mode 100644
index 00000000..194718b8
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1532
@@ -0,0 +1,533 @@
+peripherals: 0.909
+KVM: 0.904
+permissions: 0.898
+virtual: 0.893
+hypervisor: 0.868
+TCG: 0.854
+device: 0.850
+vnc: 0.848
+register: 0.847
+network: 0.842
+files: 0.840
+VMM: 0.833
+risc-v: 0.822
+architecture: 0.818
+graphic: 0.818
+performance: 0.805
+PID: 0.804
+boot: 0.803
+mistranslation: 0.799
+debug: 0.783
+ppc: 0.776
+arm: 0.768
+assembly: 0.763
+user-level: 0.754
+kernel: 0.721
+semantic: 0.720
+x86: 0.686
+socket: 0.684
+i386: 0.457
+
+libivrtd fork qemu to create vm ,which start with ceph rbd device, after vm status:runing , the qemu stuck at booting from hard disk....
+Description of problem:
+[root@ceph-client ceph]# virsh list --all
+ Id    Name                           State
+----------------------------------------------------
+ 19    c7_ceph                        running
+
+the vm qemu stuck at booting from hard disk.....
+Steps to reproduce:
+1. use ceph-deploy deploy a ceph distribute storage, which use to store vm's qcow2 files,this ceph has 3 osd node 
+2. refer the link https://docs.ceph.com/en/quincy/rbd/libvirt/  create a ceph user :client.libvirt 
+3. import a exists qcow2 file into ceph libvit-pool, then start vm
+
+[root@ceph-1 ~]# ceph -s
+  cluster:
+    id:     3fbbf51f-88fd-4883-9f24-595bf853c5f2
+    health: HEALTH_OK
+ 
+  services:
+    mon: 1 daemons, quorum ceph-1
+    mgr: ceph-1(active)
+    osd: 3 osds: 3 up, 3 in
+ 
+  data:
+    pools:   1 pools, 128 pgs
+    objects: 940  objects, 3.6 GiB
+    usage:   31 GiB used, 209 GiB / 240 GiB avail
+    pgs:     128 active+clean
+
+[root@ceph-1 ~]#ceph auth ls  
+client.libvirt
+	key: AQD/XwFkq7kHMhAA1OmPtKPVno6gjmZleOevOA==
+	caps: [mon] allow r
+	caps: [osd] allow class-read object_prefix rbd_children, allow rwx pool=libvirt-pool
+
+[root@ceph-client ceph]# cat ceph.conf 
+[global]
+fsid = 3fbbf51f-88fd-4883-9f24-595bf853c5f2
+mon_initial_members = ceph-1
+mon_host = 172.24.193.62
+auth_cluster_required = cephx
+auth_service_required = cephx
+auth_client_required = cephx
+
+osd_pool_default_size = 2
+[root@ceph-client ceph]# 
+
+[root@ceph-client ceph]# virsh start c7_ceph
+Domain c7_ceph started
+
+[root@ceph-client ceph]# 
+[root@ceph-client ceph]# virsh list --all
+ Id    Name                           State
+----------------------------------------------------
+ 19    c7_ceph                        running
+
+
+    <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator>
+    <disk type='network' device='disk'>
+      <driver name='qemu' type='raw' cache='writeback'/>
+      <auth username='libvirt'>
+        <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/>
+      </auth>
+      <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2'>
+        <host name='172.24.193.62' port='6789'/>
+        <host name='172.24.193.63' port='6789'/>
+        <host name='172.24.193.64' port='6789'/>
+      </source>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+    </disk>
+
+========================
+[root@ceph-client ceph]# cat /run/libvirt/qemu/c7_ceph.xml 
+
+
+<domstatus state='running' reason='booted' pid='57437'>
+  <monitor path='/var/lib/libvirt/qemu/domain-19-c7_ceph/monitor.sock' json='1' type='unix'/>
+  <namespaces>
+    <mount/>
+  </namespaces>
+  <vcpus>
+    <vcpu id='0' pid='57487'/>
+    <vcpu id='1' pid='57488'/>
+  </vcpus>
+  <qemuCaps>
+    <flag name='kvm'/>
+    <flag name='no-hpet'/>
+    <flag name='spice'/>
+    <flag name='boot-index'/>
+    <flag name='hda-duplex'/>
+    <flag name='ccid-emulated'/>
+    <flag name='ccid-passthru'/>
+    <flag name='virtio-tx-alg'/>
+    <flag name='virtio-blk-pci.ioeventfd'/>
+    <flag name='sga'/>
+    <flag name='virtio-blk-pci.event_idx'/>
+    <flag name='virtio-net-pci.event_idx'/>
+    <flag name='piix3-usb-uhci'/>
+    <flag name='piix4-usb-uhci'/>
+    <flag name='usb-ehci'/>
+    <flag name='ich9-usb-ehci1'/>
+    <flag name='vt82c686b-usb-uhci'/>
+    <flag name='pci-ohci'/>
+    <flag name='usb-redir'/>
+    <flag name='usb-hub'/>
+    <flag name='ich9-ahci'/>
+    <flag name='no-acpi'/>
+    <flag name='virtio-blk-pci.scsi'/>
+    <flag name='scsi-disk.channel'/>
+    <flag name='scsi-block'/>
+    <flag name='transaction'/>
+    <flag name='block-job-async'/>
+    <flag name='scsi-cd'/>
+    <flag name='ide-cd'/>
+    <flag name='hda-micro'/>
+    <flag name='dump-guest-memory'/>
+    <flag name='nec-usb-xhci'/>
+    <flag name='balloon-event'/>
+    <flag name='lsi'/>
+    <flag name='virtio-scsi-pci'/>
+    <flag name='blockio'/>
+    <flag name='disable-s3'/>
+    <flag name='disable-s4'/>
+    <flag name='usb-redir.filter'/>
+    <flag name='ide-drive.wwn'/>
+    <flag name='scsi-disk.wwn'/>
+    <flag name='seccomp-sandbox'/>
+    <flag name='reboot-timeout'/>
+    <flag name='seamless-migration'/>
+    <flag name='block-commit'/>
+    <flag name='vnc'/>
+    <flag name='drive-mirror'/>
+    <flag name='usb-redir.bootindex'/>
+    <flag name='usb-host.bootindex'/>
+    <flag name='blockdev-snapshot-sync'/>
+    <flag name='qxl'/>
+    <flag name='VGA'/>
+    <flag name='cirrus-vga'/>
+    <flag name='vmware-svga'/>
+    <flag name='device-video-primary'/>
+    <flag name='usb-serial'/>
+    <flag name='usb-net'/>
+    <flag name='add-fd'/>
+    <flag name='nbd-server'/>
+    <flag name='virtio-rng'/>
+    <flag name='rng-random'/>
+    <flag name='rng-egd'/>
+    <flag name='megasas'/>
+    <flag name='tpm-passthrough'/>
+    <flag name='tpm-tis'/>
+    <flag name='pci-bridge'/>
+    <flag name='vfio-pci'/>
+    <flag name='vfio-pci.bootindex'/>
+    <flag name='scsi-generic'/>
+    <flag name='scsi-generic.bootindex'/>
+    <flag name='mem-merge'/>
+    <flag name='vnc-websocket'/>
+    <flag name='drive-discard'/>
+    <flag name='mlock'/>
+    <flag name='device-del-event'/>
+    <flag name='dmi-to-pci-bridge'/>
+    <flag name='i440fx-pci-hole64-size'/>
+    <flag name='q35-pci-hole64-size'/>
+    <flag name='usb-storage'/>
+    <flag name='usb-storage.removable'/>
+    <flag name='ich9-intel-hda'/>
+    <flag name='kvm-pit-lost-tick-policy'/>
+    <flag name='boot-strict'/>
+    <flag name='pvpanic'/>
+    <flag name='spice-file-xfer-disable'/>
+    <flag name='spiceport'/>
+    <flag name='usb-kbd'/>
+    <flag name='msg-timestamp'/>
+    <flag name='active-commit'/>
+    <flag name='change-backing-file'/>
+    <flag name='memory-backend-ram'/>
+    <flag name='numa'/>
+    <flag name='memory-backend-file'/>
+    <flag name='usb-audio'/>
+    <flag name='rtc-reset-reinjection'/>
+    <flag name='splash-timeout'/>
+    <flag name='iothread'/>
+    <flag name='migrate-rdma'/>
+    <flag name='ivshmem'/>
+    <flag name='drive-iotune-max'/>
+    <flag name='VGA.vgamem_mb'/>
+    <flag name='vmware-svga.vgamem_mb'/>
+    <flag name='qxl.vgamem_mb'/>
+    <flag name='pc-dimm'/>
+    <flag name='machine-vmport-opt'/>
+    <flag name='aes-key-wrap'/>
+    <flag name='dea-key-wrap'/>
+    <flag name='pci-serial'/>
+    <flag name='vhost-user-multiqueue'/>
+    <flag name='migration-event'/>
+    <flag name='ioh3420'/>
+    <flag name='x3130-upstream'/>
+    <flag name='xio3130-downstream'/>
+    <flag name='rtl8139'/>
+    <flag name='e1000'/>
+    <flag name='virtio-net'/>
+    <flag name='gic-version'/>
+    <flag name='incoming-defer'/>
+    <flag name='virtio-gpu'/>
+    <flag name='virtio-keyboard'/>
+    <flag name='virtio-mouse'/>
+    <flag name='virtio-tablet'/>
+    <flag name='virtio-input-host'/>
+    <flag name='chardev-file-append'/>
+    <flag name='ich9-disable-s3'/>
+    <flag name='ich9-disable-s4'/>
+    <flag name='vserport-change-event'/>
+    <flag name='virtio-balloon-pci.deflate-on-oom'/>
+    <flag name='mptsas1068'/>
+    <flag name='qxl.vram64_size_mb'/>
+    <flag name='chardev-logfile'/>
+    <flag name='debug-threads'/>
+    <flag name='secret'/>
+    <flag name='pxb'/>
+    <flag name='pxb-pcie'/>
+    <flag name='device-tray-moved-event'/>
+    <flag name='nec-usb-xhci-ports'/>
+    <flag name='virtio-scsi-pci.iothread'/>
+    <flag name='name-guest'/>
+    <flag name='qxl.max_outputs'/>
+    <flag name='spice-unix'/>
+    <flag name='drive-detect-zeroes'/>
+    <flag name='tls-creds-x509'/>
+    <flag name='intel-iommu'/>
+    <flag name='smm'/>
+    <flag name='virtio-pci-disable-legacy'/>
+    <flag name='query-hotpluggable-cpus'/>
+    <flag name='virtio-net.rx_queue_size'/>
+    <flag name='virtio-vga'/>
+    <flag name='drive-iotune-max-length'/>
+    <flag name='ivshmem-plain'/>
+    <flag name='ivshmem-doorbell'/>
+    <flag name='query-qmp-schema'/>
+    <flag name='gluster.debug_level'/>
+    <flag name='drive-iotune-group'/>
+    <flag name='query-cpu-model-expansion'/>
+    <flag name='virtio-net.host_mtu'/>
+    <flag name='nvdimm'/>
+    <flag name='pcie-root-port'/>
+    <flag name='query-cpu-definitions'/>
+    <flag name='block-write-threshold'/>
+    <flag name='query-named-block-nodes'/>
+    <flag name='cpu-cache'/>
+    <flag name='qemu-xhci'/>
+    <flag name='kernel-irqchip'/>
+    <flag name='kernel-irqchip.split'/>
+    <flag name='intel-iommu.intremap'/>
+    <flag name='intel-iommu.caching-mode'/>
+    <flag name='intel-iommu.eim'/>
+    <flag name='intel-iommu.device-iotlb'/>
+    <flag name='virtio.iommu_platform'/>
+    <flag name='virtio.ats'/>
+    <flag name='loadparm'/>
+    <flag name='vnc-multi-servers'/>
+    <flag name='virtio-net.tx_queue_size'/>
+    <flag name='chardev-reconnect'/>
+    <flag name='virtio-gpu.max_outputs'/>
+    <flag name='vxhs'/>
+    <flag name='virtio-blk.num-queues'/>
+    <flag name='vmcoreinfo'/>
+    <flag name='numa.dist'/>
+    <flag name='disk-share-rw'/>
+    <flag name='iscsi.password-secret'/>
+    <flag name='isa-serial'/>
+    <flag name='dump-completed'/>
+    <flag name='qcow2-luks'/>
+    <flag name='pcie-pci-bridge'/>
+    <flag name='seccomp-blacklist'/>
+    <flag name='query-cpus-fast'/>
+    <flag name='disk-write-cache'/>
+    <flag name='nbd-tls'/>
+    <flag name='tpm-crb'/>
+    <flag name='pr-manager-helper'/>
+    <flag name='qom-list-properties'/>
+    <flag name='memory-backend-file.discard-data'/>
+    <flag name='sdl-gl'/>
+    <flag name='screendump_device'/>
+    <flag name='hda-output'/>
+    <flag name='blockdev-del'/>
+    <flag name='vmgenid'/>
+    <flag name='vhost-vsock'/>
+    <flag name='chardev-fd-pass'/>
+    <flag name='tpm-emulator'/>
+    <flag name='mch'/>
+    <flag name='mch.extended-tseg-mbytes'/>
+    <flag name='usb-storage.werror'/>
+    <flag name='egl-headless'/>
+    <flag name='vfio-pci.display'/>
+  </qemuCaps>
+  <devices>
+    <device alias='rng0'/>
+    <device alias='virtio-disk0'/>
+    <device alias='virtio-serial0'/>
+    <device alias='video0'/>
+    <device alias='serial0'/>
+    <device alias='balloon0'/>
+    <device alias='channel0'/>
+    <device alias='net0'/>
+    <device alias='input0'/>
+    <device alias='scsi0'/>
+    <device alias='usb'/>
+  </devices>
+  <libDir path='/var/lib/libvirt/qemu/domain-19-c7_ceph'/>
+  <channelTargetDir path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph'/>
+  <cpu mode='custom' match='exact' check='partial'>
+    <model fallback='forbid'>Broadwell</model>
+  </cpu>
+  <chardevStdioLogd/>
+  <allowReboot value='yes'/>
+  <blockjobs active='no'/>
+  <domain type='kvm' id='19'>
+    <name>c7_ceph</name>
+    <uuid>ff08671e-824c-4939-80ec-602235c0662e</uuid>
+    <memory unit='KiB'>4194304</memory>
+    <currentMemory unit='KiB'>4194304</currentMemory>
+    <vcpu placement='static'>2</vcpu>
+    <resource>
+      <partition>/machine</partition>
+    </resource>
+    <os>
+      <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type>
+      <boot dev='hd'/>
+    </os>
+    <features>
+      <acpi/>
+      <apic/>
+    </features>
+    <cpu mode='custom' match='exact' check='full'>
+      <model fallback='forbid'>Broadwell</model>
+      <feature policy='require' name='vme'/>
+      <feature policy='require' name='f16c'/>
+      <feature policy='require' name='rdrand'/>
+      <feature policy='require' name='hypervisor'/>
+      <feature policy='require' name='arat'/>
+      <feature policy='disable' name='erms'/>
+      <feature policy='require' name='xsaveopt'/>
+      <feature policy='require' name='abm'/>
+    </cpu>
+    <clock offset='utc'>
+      <timer name='rtc' tickpolicy='catchup'/>
+      <timer name='pit' tickpolicy='delay'/>
+      <timer name='hpet' present='no'/>
+    </clock>
+    <on_poweroff>destroy</on_poweroff>
+    <on_reboot>restart</on_reboot>
+    <on_crash>destroy</on_crash>
+    <pm>
+      <suspend-to-mem enabled='no'/>
+      <suspend-to-disk enabled='no'/>
+    </pm>
+    <devices>
+      <emulator>/usr/local/qemu-3.0/bin/qemu-system-x86_64</emulator>
+      <disk type='network' device='disk'>
+        <driver name='qemu' type='raw' cache='writeback'/>
+        <auth username='libvirt'>
+          <secret type='ceph' uuid='fb57a2a3-8cdf-44cb-afc1-2d8bdc0fc5d0'/>
+        </auth>
+        <source protocol='rbd' name='libvirt-pool/root-vsys_c5.qcow2' tlsFromConfig='0'>
+          <host name='172.24.193.62' port='6789'/>
+          <host name='172.24.193.63' port='6789'/>
+          <host name='172.24.193.64' port='6789'/>
+          <privateData>
+            <objects>
+              <secret type='auth' alias='virtio-disk0-secret0'/>
+            </objects>
+          </privateData>
+        </source>
+        <target dev='vda' bus='virtio'/>
+        <alias name='virtio-disk0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+      </disk>
+      <controller type='usb' index='0' model='ich9-ehci1'>
+        <alias name='usb'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x7'/>
+      </controller>
+      <controller type='usb' index='0' model='ich9-uhci1'>
+        <alias name='usb'/>
+        <master startport='0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/>
+      </controller>
+      <controller type='usb' index='0' model='ich9-uhci2'>
+        <alias name='usb'/>
+        <master startport='2'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/>
+      </controller>
+      <controller type='usb' index='0' model='ich9-uhci3'>
+        <alias name='usb'/>
+        <master startport='4'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x2'/>
+      </controller>
+      <controller type='pci' index='0' model='pci-root'>
+        <alias name='pci.0'/>
+      </controller>
+      <controller type='virtio-serial' index='0'>
+        <alias name='virtio-serial0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+      </controller>
+      <controller type='scsi' index='0' model='lsilogic'>
+        <alias name='scsi0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+      </controller>
+      <controller type='ide' index='0'>
+        <alias name='ide'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+      </controller>
+      <interface type='bridge'>
+        <mac address='52:54:00:2e:e1:1f'/>
+        <source bridge='virbr0'/>
+        <target dev='vnet0'/>
+        <model type='virtio'/>
+        <alias name='net0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+      </interface>
+      <serial type='pty'>
+        <source path='/dev/pts/2'/>
+        <target type='isa-serial' port='0'>
+          <model name='isa-serial'/>
+        </target>
+        <alias name='serial0'/>
+      </serial>
+      <console type='pty' tty='/dev/pts/2'>
+        <source path='/dev/pts/2'/>
+        <target type='serial' port='0'/>
+        <alias name='serial0'/>
+      </console>
+      <channel type='unix'>
+        <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-19-c7_ceph/org.qemu.guest_agent.0'/>
+        <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
+        <alias name='channel0'/>
+        <address type='virtio-serial' controller='0' bus='0' port='1'/>
+      </channel>
+      <input type='tablet' bus='usb'>
+        <alias name='input0'/>
+        <address type='usb' bus='0' port='1'/>
+      </input>
+      <input type='mouse' bus='ps2'>
+        <alias name='input1'/>
+      </input>
+      <input type='keyboard' bus='ps2'>
+        <alias name='input2'/>
+      </input>
+      <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'>
+        <listen type='address' address='0.0.0.0' fromConfig='0' autoGenerated='no'/>
+      </graphics>
+      <video>
+        <model type='cirrus' vram='16384' heads='1' primary='yes'/>
+        <alias name='video0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+      </video>
+      <memballoon model='virtio'>
+        <alias name='balloon0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+      </memballoon>
+      <rng model='virtio'>
+        <backend model='random'>/dev/urandom</backend>
+        <alias name='rng0'/>
+        <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
+      </rng>
+    </devices>
+    <seclabel type='dynamic' model='selinux' relabel='yes'>
+      <label>system_u:system_r:svirt_t:s0:c99,c659</label>
+      <imagelabel>system_u:object_r:svirt_image_t:s0:c99,c659</imagelabel>
+    </seclabel>
+    <seclabel type='dynamic' model='dac' relabel='yes'>
+      <label>+107:+107</label>
+      <imagelabel>+107:+107</imagelabel>
+    </seclabel>
+  </domain>
+</domstatus>
+[root@ceph-client ceph]# 
+
+/usr/local/qemu-3.0/bin/qemu-system-x86_64 which is build by qemu-3.0 source code , first i build qemu-3.0 source with --enable-rbd ,
+later i rebuild qemu-3.0 source with more config paramter from centos7-2009 qemu, those config paramter from qemu-kvm-1.5.3-175.el7.src.rpm ,which has those paramters:
+# QEMU configure log Fri Mar  3 18:22:31 CST 2023
+# Configured with: './configure' '--prefix=/usr' '--libdir=/usr/lib64' '--sysconfdir=/etc' '--interp-prefix=/usr/qemu-%M' '--audio-drv-list=pa,alsa' '--with-confsuffix=/qemu-kvm' '--localstatedir=/var' '--libexecdir=/usr/libexec' '--wit
+h-pkgversion=qemu-kvm-1.5.3-175.el7' '--disable-strip' '--disable-qom-cast-debug' '--extra-ldflags=-Wl,--build-id -pie -Wl,-z,relro -Wl,-z,now' '--extra-cflags=-O2 -g -pipe -Wall  -fexceptions -fstack-protector-strong --param=ssp-buffer
+-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIE -DPIE' '--enable-trace-backend=dtrace' '--enable-werror' '--disable-xen' '--disable-virtfs' '--enable-kvm' '--enable-libusb' '--enable-spice' '--enable-seccomp' '--disable-fdt' '--
+enable-docs' '--disable-sdl' '--disable-debug-tcg' '--disable-sparse' '--disable-brlapi' '--disable-bluez' '--disable-vde' '--disable-curses' '--enable-curl' '--enable-libssh2' '--enable-vnc-tls' '--enable-vnc-sasl' '--enable-linux-aio'
+ '--enable-smartcard-nss' '--enable-lzo' '--enable-snappy' '--enable-usb-redir' '--enable-vnc-png' '--disable-vnc-jpeg' '--enable-vnc-ws' '--enable-uuid' '--disable-vhost-scsi' '--disable-guest-agent' '--disable-live-block-ops' '--disab
+le-live-block-migration' '--enable-rbd' '--enable-glusterfs' '--enable-tcmalloc' '--block-drv-rw-whitelist=qcow2,raw,file,host_device,blkdebug,nbd,iscsi,gluster,rbd' '--block-drv-ro-whitelist=vmdk,vhdx,vpc,ssh,https' '--iasl=/bin/false'
+ '--target-list=x86_64-softmmu'
+
+
+,   after rebuild the qemu-system-x86_64 : 
+
+virsh start c7_ceph 
+[root@ceph-client ceph]# virsh list --all
+ Id    Name                           State
+----------------------------------------------------
+ 19    c7_ceph                        running
+
+qemu still stuck at booting from hard disk...
+
+
+
+to my surprised if the libvirtd xml file if i replace /usr/local/qemu-3.0/bin/qemu-system-x86_64 with /usr/libexec/bin/qemu-kvm , then the vm
+can start successfully .
diff --git a/results/classifier/zero-shot/118/peripherals/1538541 b/results/classifier/zero-shot/118/peripherals/1538541
new file mode 100644
index 00000000..533b854b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1538541
@@ -0,0 +1,95 @@
+peripherals: 0.934
+ppc: 0.902
+user-level: 0.902
+graphic: 0.901
+risc-v: 0.894
+KVM: 0.890
+vnc: 0.888
+hypervisor: 0.887
+semantic: 0.880
+debug: 0.874
+mistranslation: 0.872
+assembly: 0.862
+register: 0.858
+VMM: 0.852
+PID: 0.848
+TCG: 0.840
+virtual: 0.839
+performance: 0.832
+permissions: 0.819
+arm: 0.819
+device: 0.811
+network: 0.796
+socket: 0.780
+x86: 0.780
+kernel: 0.773
+architecture: 0.771
+boot: 0.740
+files: 0.686
+i386: 0.486
+
+qcow2 rejects request to use preallocation with backing file
+
+The 'preallocation=full' option to qemu-img / qcow2 block driver instructs QEMU to fully allocate the host file to the maximum size needed by the logical disk size.
+
+$ qemu-img create -f qcow2 -o preallocation=full base.qcow2 200M
+Formatting 'base.qcow2', fmt=qcow2 size=209715200 encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16
+
+$ ls -alhs base.qcow2 
+201M -rw-r--r--. 1 berrange berrange 201M Jan 27 12:49 base.qcow2
+
+
+When specifying a backing file for the qcow2 file, however, it rejects the preallocation request
+
+$ qemu-img create -f qcow2 -o preallocation=full,backing_file=base.qcow2 front.qcow2 200M
+Formatting 'front.qcow2', fmt=qcow2 size=209715200 backing_file='base.qcow2' encryption=off cluster_size=65536 preallocation='full' lazy_refcounts=off refcount_bits=16
+qemu-img: front.qcow2: Backing file and preallocation cannot be used at the same time
+
+
+It might seem like requesting full preallocation is redundant because most data associated with the image will be present in the backing file, as so the top layer is unlikely to ever need the full preallocation.  Rejecting this, however, means it is not (officially) possible to reserve disk space for the top layer to guarantee that future copy-on-writes will never get ENOSPC.
+
+OpenStack in particular uses backing files with all images, in order to avoid the I/O overhead of copying the backing file contents into the per-VM disk image. It, however, still wants to have a guarantee that the per-VM image will never hit an ENOSPC scenario.
+
+Currently it has to hack around QEMU's refusal to allow backing_file + preallocation, by calling 'fallocate' on the qcow2 file after it has been created. This is an inexact fix though, because it doesn't take account of fact that qcow2 metadata can takes some MBs of space.
+
+Thus, it would like to see preallocation=full supported in combination with backing files.
+
+Using any preallocation value other than none will result in all data clusters of the new image being used. That means that any I/O request will be served by that image, and never by the backing file. This is why preallocating an image with a backing file is not supported, because it generally doesn't make any sense. The backing file will never be seen anyway.
+
+In order to support this, qcow2 will need to support preallocated data clusters which are explicitly marked as empty (where "empty" is not "zero"; "empty" means "fall through to the backing file"). This has been proposed before, but has not been implemented so far.
+
+By the way, this is the very reason why explicitly forbidding the combination of backing file and preallocation is very reasonable: Right now, the backing file would be invisible, a preallocated image always returns zeros when read. With the above feature implemented, the backing file would be visible. In order to allow this change in behavior, we have to make the combination an error for now.
+
+Max
+
+PS: The reason I write this is so that you know that this is not a bug, but correct behavior in view of a missing feature (that should indeed be implemented).
+
+> In order to support this, qcow2 will need to support preallocated data clusters which are explicitly marked as empty (where "empty" is not "zero"; "empty" means "fall through to the backing file"). This has been proposed before, but has not been implemented so far.
+
+This sounds like a bit of extra work, but I'm puzzelled why we can't have a preallocation option which simply calls fallocate() to grow the file to the right size. From qcow2 pov, the extra clusters won't be allocated - we're just making sure the filesystem has reserved sufficient space for when qcow2 does later allocate the clusters during a copy-on-write.  Perhaps this would imply a new option to the 'preallocation' option rather than 'full'
+
+The idea that qcow2 could just reserve enough space that it will never need any additional clusters stands on somewhat shaky ground anyway. You can count in metadata such as refcount tables/blocks and the L1/L2 table for an image with the full virtual disk size used. This doesn't cover things like snapshots or in the future bitmaps; I'm not completely sure, but it might also fail to cover some scenarios that involve discard and where some space isn't immediately reused due to image fragmentation. Whether or not a given static size is sufficient for an image depends primarily on how the image is going to be used.
+
+What you seem to want isn't really qcow2 preallocation (which would involve, as Max said, preallocating all clusters on the qcow2 level), but preallocation of the image file in the file system layer to a size that matches your use of qcow2. I'm afraid that doing this in the management layer, which actually knows best how it's going to use the image, makes more sense than letting qemu guess and implement a hack that preallocates only on the file system, but not the image format level.
+
+Preallocating the understanding image file at the management layer though means that the mgmt tool has to understand the full details of the qcow2 file format. The mgmt layer knows it created a 20 GB qcow2 file, but does not know that once you have stored 20 GB of user data in it, it will actually consume  20 GB + NNN MB extra. Calculating hat NNN MB extra is trivial for qemu since it knows the file format already, but hard for the mgmt app
+
+It is not exactly trivial, and it being in qemu does not make it simpler. http://git.qemu.org/?p=qemu.git;a=blob;f=block/qcow2.c;h=fd8436c5f8b13ab0e8c605147ce76e6b6a8e5f95;hb=HEAD#l2105 is the code that calculates the size; as you can see, it is pretty self-contained.
+
+Max
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1547526 b/results/classifier/zero-shot/118/peripherals/1547526
new file mode 100644
index 00000000..17bb23ad
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1547526
@@ -0,0 +1,447 @@
+peripherals: 0.838
+user-level: 0.824
+virtual: 0.805
+ppc: 0.790
+device: 0.782
+graphic: 0.768
+architecture: 0.757
+debug: 0.747
+register: 0.744
+performance: 0.741
+hypervisor: 0.734
+mistranslation: 0.729
+permissions: 0.726
+TCG: 0.719
+PID: 0.712
+risc-v: 0.709
+semantic: 0.696
+VMM: 0.671
+boot: 0.669
+vnc: 0.645
+arm: 0.641
+files: 0.633
+network: 0.499
+assembly: 0.481
+socket: 0.463
+KVM: 0.461
+kernel: 0.409
+x86: 0.361
+i386: 0.233
+
+Java program does not execute on SPARC Solaris 8
+
+Hello, 
+
+I am trying to run a java program that never execute. The program uses jre1.1.5 which came with the java program. I don't know what to do to run this application. There are some random messages in command line that can be related to my problem (or not). They are:
+
+	#1. Webstart launcher crashing.
+	Also found here: http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html
+
+	#2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, line 766
+	Which was already reported here: https://bugs.launchpad.net/qemu/+bug/1450881
+
+	#3. Some problems with libthread in Solaris. 
+	I have tried a workaround setting LM_LIBRARY_PATH to use another version of libthread that Solaris 8 has.
+
+I don't know if this is a qemu problem or Solaris problem.
+My java application can be executed in command line or in GUI but I've tried both with no luck. I also have tryed other versions of JRE from 1.1.8 to 1.5 but no luck either.
+
+I appreciate **any information** that can help me to execute the java program!!
+Thank you.
+
+I am using qemu-system-sparc (v2.5.50) with Solaris 8 (solaris-8-hw4-2.04-sparc).
+The host is an Ubuntu 15.10 and I am using the openbios-sparc from Ubuntus ppa as shown bellow:
+
+	openbios-sparc | 1.1+svn1334-1 | http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages
+
+The command line used to launch qemu is:
+
+	qemu-system-sparc \
+		-M SS-5 \
+		-m 256 \
+		-boot c \
+		-cdrom $(DATA_ISO) \
+		-drive file=root-disk.img,index=0,media=disk,format=raw \
+		-serial stdio \
+		-monitor tcp::4444,server,nowait \
+		-localtime \
+		-net user \
+		-net nic \
+		$(ui)
+
+DATA_ISO is the way I found to send my data to the guest.
+
+The root-disk.img is:
+
+	Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors
+	Geometry: 27 heads, 107 sectors/track, 24620 cylinders
+	Units: sectors of 1 * 512 = 512 bytes
+	Sector size (logical/physical): 512 bytes / 512 bytes
+	I/O size (minimum/optimal): 512 bytes / 512 bytes
+	Disklabel type: sun
+
+	Device           Start      End  Sectors   Size Id Type       Flags
+	root-disk.img1       0  2744549  2744550   1.3G  2 SunOS root      
+	root-disk.img2 2744550  3047894   303345 148.1M  3 SunOS swap    u 
+	root-disk.img3       0 71127179 71127180  33.9G  5 Whole disk      
+	root-disk.img8 3047895 71127179 68079285  32.5G  8 SunOS home      
+
+	image: root-disk.img
+	file format: raw
+	virtual size: 36G (38654705664 bytes)
+	disk size: 1.2G
+
+I've been looking at this as I have time, and IMO it's a qemu bug. Fortunately I have a easy local reproducer here, and from what I can see in this one particular case it seems the QEMU doesn't honour the annul bit in the branch (or apparently corrupts it according to the guest?!). So yes, it's a known issue and I am working hard to try and isolate the bug and come up with a fix.
+
+Hi Mark, it is very good to hear that it isn't only with me.
+
+Let me know if you need a help to test and/or collect any information to help you to discover/fix this problem.
+
+Proposed patch posted to mailing list: https://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg01645.html - please test and report back.
+
+
+Great Mark! This patch solves my problem. Thank you very much. 
+
+Patch that solves the problem.
+
+Leandro, thanks for testing on your setup. If it passes my local tests, I'll send it in for the QEMU 2.6 release.
+
+Good! I tested with QEMU from git that I did the clone now. It shows
+version 2.5.91.
+
+On Mon, Apr 11, 2016, 11:36 Mark Cave-Ayland <email address hidden>
+wrote:
+
+> Leandro, thanks for testing on your setup. If it passes my local tests,
+> I'll send it in for the QEMU 2.6 release.
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1547526
+>
+> Title:
+>   Java program does not execute on SPARC Solaris 8
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Hello,
+>
+>   I am trying to run a java program that never execute. The program uses
+>   jre1.1.5 which came with the java program. I don't know what to do to
+>   run this application. There are some random messages in command line
+>   that can be related to my problem (or not). They are:
+>
+>         #1. Webstart launcher crashing.
+>         Also found here:
+> http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html
+>
+>         #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c,
+> line 766
+>         Which was already reported here:
+> https://bugs.launchpad.net/qemu/+bug/1450881
+>
+>         #3. Some problems with libthread in Solaris.
+>         I have tried a workaround setting LM_LIBRARY_PATH to use another
+> version of libthread that Solaris 8 has.
+>
+>   I don't know if this is a qemu problem or Solaris problem.
+>   My java application can be executed in command line or in GUI but I've
+> tried both with no luck. I also have tryed other versions of JRE from 1.1.8
+> to 1.5 but no luck either.
+>
+>   I appreciate **any information** that can help me to execute the java
+> program!!
+>   Thank you.
+>
+>   I am using qemu-system-sparc (v2.5.50) with Solaris 8
+> (solaris-8-hw4-2.04-sparc).
+>   The host is an Ubuntu 15.10 and I am using the openbios-sparc from
+> Ubuntus ppa as shown bellow:
+>
+>           openbios-sparc | 1.1+svn1334-1 |
+>   http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages
+>
+>   The command line used to launch qemu is:
+>
+>         qemu-system-sparc \
+>                 -M SS-5 \
+>                 -m 256 \
+>                 -boot c \
+>                 -cdrom $(DATA_ISO) \
+>                 -drive file=root-disk.img,index=0,media=disk,format=raw \
+>                 -serial stdio \
+>                 -monitor tcp::4444,server,nowait \
+>                 -localtime \
+>                 -net user \
+>                 -net nic \
+>                 $(ui)
+>
+>   DATA_ISO is the way I found to send my data to the guest.
+>
+>   The root-disk.img is:
+>
+>         Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors
+>         Geometry: 27 heads, 107 sectors/track, 24620 cylinders
+>         Units: sectors of 1 * 512 = 512 bytes
+>         Sector size (logical/physical): 512 bytes / 512 bytes
+>         I/O size (minimum/optimal): 512 bytes / 512 bytes
+>         Disklabel type: sun
+>
+>         Device           Start      End  Sectors   Size Id Type       Flags
+>         root-disk.img1       0  2744549  2744550   1.3G  2 SunOS root
+>         root-disk.img2 2744550  3047894   303345 148.1M  3 SunOS swap    u
+>         root-disk.img3       0 71127179 71127180  33.9G  5 Whole disk
+>         root-disk.img8 3047895 71127179 68079285  32.5G  8 SunOS home
+>
+>         image: root-disk.img
+>         file format: raw
+>         virtual size: 36G (38654705664 bytes)
+>         disk size: 1.2G
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1547526/+subscriptions
+>
+-- 
+Leandro S. Heck
+
+
+Hi Mark, do you know when qemu 2.6 will be released?
+
+--
+Leandro Sehnem Heck
+
+On Fri, Apr 15, 2016 at 4:49 AM, Mark Cave-Ayland <
+<email address hidden>> wrote:
+
+> *** This bug is a duplicate of bug 1450881 ***
+>     https://bugs.launchpad.net/bugs/1450881
+>
+> ** This bug has been marked a duplicate of bug 1450881
+>    qemu-system-sparc MUTEX_HELD assert and libC lock errors
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1547526
+>
+> Title:
+>   Java program does not execute on SPARC Solaris 8
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Hello,
+>
+>   I am trying to run a java program that never execute. The program uses
+>   jre1.1.5 which came with the java program. I don't know what to do to
+>   run this application. There are some random messages in command line
+>   that can be related to my problem (or not). They are:
+>
+>         #1. Webstart launcher crashing.
+>         Also found here:
+> http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html
+>
+>         #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c,
+> line 766
+>         Which was already reported here:
+> https://bugs.launchpad.net/qemu/+bug/1450881
+>
+>         #3. Some problems with libthread in Solaris.
+>         I have tried a workaround setting LM_LIBRARY_PATH to use another
+> version of libthread that Solaris 8 has.
+>
+>   I don't know if this is a qemu problem or Solaris problem.
+>   My java application can be executed in command line or in GUI but I've
+> tried both with no luck. I also have tryed other versions of JRE from 1.1.8
+> to 1.5 but no luck either.
+>
+>   I appreciate **any information** that can help me to execute the java
+> program!!
+>   Thank you.
+>
+>   I am using qemu-system-sparc (v2.5.50) with Solaris 8
+> (solaris-8-hw4-2.04-sparc).
+>   The host is an Ubuntu 15.10 and I am using the openbios-sparc from
+> Ubuntus ppa as shown bellow:
+>
+>           openbios-sparc | 1.1+svn1334-1 |
+>   http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages
+>
+>   The command line used to launch qemu is:
+>
+>         qemu-system-sparc \
+>                 -M SS-5 \
+>                 -m 256 \
+>                 -boot c \
+>                 -cdrom $(DATA_ISO) \
+>                 -drive file=root-disk.img,index=0,media=disk,format=raw \
+>                 -serial stdio \
+>                 -monitor tcp::4444,server,nowait \
+>                 -localtime \
+>                 -net user \
+>                 -net nic \
+>                 $(ui)
+>
+>   DATA_ISO is the way I found to send my data to the guest.
+>
+>   The root-disk.img is:
+>
+>         Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors
+>         Geometry: 27 heads, 107 sectors/track, 24620 cylinders
+>         Units: sectors of 1 * 512 = 512 bytes
+>         Sector size (logical/physical): 512 bytes / 512 bytes
+>         I/O size (minimum/optimal): 512 bytes / 512 bytes
+>         Disklabel type: sun
+>
+>         Device           Start      End  Sectors   Size Id Type       Flags
+>         root-disk.img1       0  2744549  2744550   1.3G  2 SunOS root
+>         root-disk.img2 2744550  3047894   303345 148.1M  3 SunOS swap    u
+>         root-disk.img3       0 71127179 71127180  33.9G  5 Whole disk
+>         root-disk.img8 3047895 71127179 68079285  32.5G  8 SunOS home
+>
+>         image: root-disk.img
+>         file format: raw
+>         virtual size: 36G (38654705664 bytes)
+>         disk size: 1.2G
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1547526/+subscriptions
+>
+
+
+On 05/02/2016 09:50 PM, Leandro Heck wrote:
+> *** This bug is a duplicate of bug 1450881 ***
+>     https://bugs.launchpad.net/bugs/1450881
+> 
+> Hi Mark, do you know when qemu 2.6 will be released?
+> 
+
+Hi Leandro,
+
+please take a look here: http://wiki.qemu.org/Planning/2.6
+
+Cheers,
+Bastian
+
+
+
+Oh nice! Thank you.
+
+--
+Leandro Sehnem Heck
+
+On Mon, May 2, 2016 at 6:17 PM, Bastian Koppelmann <
+<email address hidden>> wrote:
+
+> *** This bug is a duplicate of bug 1450881 ***
+>     https://bugs.launchpad.net/bugs/1450881
+>
+> On 05/02/2016 09:50 PM, Leandro Heck wrote:
+> > *** This bug is a duplicate of bug 1450881 ***
+> >     https://bugs.launchpad.net/bugs/1450881
+> >
+> > Hi Mark, do you know when qemu 2.6 will be released?
+> >
+>
+> Hi Leandro,
+>
+> please take a look here: http://wiki.qemu.org/Planning/2.6
+>
+> Cheers,
+> Bastian
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1547526
+>
+> Title:
+>   Java program does not execute on SPARC Solaris 8
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Hello,
+>
+>   I am trying to run a java program that never execute. The program uses
+>   jre1.1.5 which came with the java program. I don't know what to do to
+>   run this application. There are some random messages in command line
+>   that can be related to my problem (or not). They are:
+>
+>         #1. Webstart launcher crashing.
+>         Also found here:
+> http://www.openfirmware.info/pipermail/openbios/2011-May/006472.html
+>
+>         #2. Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c,
+> line 766
+>         Which was already reported here:
+> https://bugs.launchpad.net/qemu/+bug/1450881
+>
+>         #3. Some problems with libthread in Solaris.
+>         I have tried a workaround setting LM_LIBRARY_PATH to use another
+> version of libthread that Solaris 8 has.
+>
+>   I don't know if this is a qemu problem or Solaris problem.
+>   My java application can be executed in command line or in GUI but I've
+> tried both with no luck. I also have tryed other versions of JRE from 1.1.8
+> to 1.5 but no luck either.
+>
+>   I appreciate **any information** that can help me to execute the java
+> program!!
+>   Thank you.
+>
+>   I am using qemu-system-sparc (v2.5.50) with Solaris 8
+> (solaris-8-hw4-2.04-sparc).
+>   The host is an Ubuntu 15.10 and I am using the openbios-sparc from
+> Ubuntus ppa as shown bellow:
+>
+>           openbios-sparc | 1.1+svn1334-1 |
+>   http://archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages
+>
+>   The command line used to launch qemu is:
+>
+>         qemu-system-sparc \
+>                 -M SS-5 \
+>                 -m 256 \
+>                 -boot c \
+>                 -cdrom $(DATA_ISO) \
+>                 -drive file=root-disk.img,index=0,media=disk,format=raw \
+>                 -serial stdio \
+>                 -monitor tcp::4444,server,nowait \
+>                 -localtime \
+>                 -net user \
+>                 -net nic \
+>                 $(ui)
+>
+>   DATA_ISO is the way I found to send my data to the guest.
+>
+>   The root-disk.img is:
+>
+>         Disk root-disk.img: 36 GiB, 38654705664 bytes, 75497472 sectors
+>         Geometry: 27 heads, 107 sectors/track, 24620 cylinders
+>         Units: sectors of 1 * 512 = 512 bytes
+>         Sector size (logical/physical): 512 bytes / 512 bytes
+>         I/O size (minimum/optimal): 512 bytes / 512 bytes
+>         Disklabel type: sun
+>
+>         Device           Start      End  Sectors   Size Id Type       Flags
+>         root-disk.img1       0  2744549  2744550   1.3G  2 SunOS root
+>         root-disk.img2 2744550  3047894   303345 148.1M  3 SunOS swap    u
+>         root-disk.img3       0 71127179 71127180  33.9G  5 Whole disk
+>         root-disk.img8 3047895 71127179 68079285  32.5G  8 SunOS home
+>
+>         image: root-disk.img
+>         file format: raw
+>         virtual size: 36G (38654705664 bytes)
+>         disk size: 1.2G
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1547526/+subscriptions
+>
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1558175 b/results/classifier/zero-shot/118/peripherals/1558175
new file mode 100644
index 00000000..96e2be84
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1558175
@@ -0,0 +1,583 @@
+peripherals: 0.935
+permissions: 0.912
+performance: 0.905
+graphic: 0.887
+hypervisor: 0.878
+virtual: 0.869
+architecture: 0.867
+register: 0.866
+semantic: 0.863
+user-level: 0.863
+assembly: 0.855
+device: 0.851
+ppc: 0.850
+network: 0.842
+debug: 0.839
+VMM: 0.835
+vnc: 0.830
+TCG: 0.820
+socket: 0.795
+PID: 0.789
+arm: 0.788
+x86: 0.780
+boot: 0.750
+i386: 0.746
+files: 0.741
+mistranslation: 0.738
+kernel: 0.729
+KVM: 0.719
+risc-v: 0.646
+
+virtio: vm killed (Guest moved used index)
+
+Hello,
+
+I ran a DPDK application with virtio ports. If I killed and relaunched it, VM is
+killed by qemu with the following message:
+> qemu-system-x86_64: Guest moved used index from 571 to 0
+
+If I ran the same application with e1000 ports, I haven't this issue.
+
+Network topology
+================
+
+I used two VM machines with last qemu-2.5 with two virtio-net netdevs. Both
+netdevs are connected through a VDE switch.
+
+On testnode, I used a Debian 8 (3.16) and virtio-net linux drivers. On DUT, I
+used a Ubuntu 14.04 (3.13) with DPDK (next/16_04) with virtio pmd.
+
++-------------------------------------------------------------+
+|                                                             |
+|  +-------------+                    +-------------------+   |
+|  |             |                    |                   |   |
+|  |   Testnode  |                    |       DUT         |   |
+|  |   Debian 8  |                    |    Ubuntu 14.04   |   |
+|  |             |    +----------+    |                   |   |
+|  |       eth0  +----+   VDE    +----+ eth0  pmd_virtio  |   |
+|  |     virtio  |    +----------+    |        00:04.0    |   |
+|  |             |                    | DE:ED:01:0C:DD:CC |   |
+|  |             |                    |                   |   |
+|  |             |    +----------+    |                   |   |
+|  |       eth1  +----+   VDE    +----+ eth1  pmd_virtio  |   |
+|  |      virtio |    +----------+    |        00:05.0    |   |
+|  |             |                    | DE:ED:02:04:01:60 |   |
+|  |             |                    |                   |   |
+|  +-------------+                    +-------------------+   |
+|     qemu 2.5                             qemu 2.5           |
+|                                                             |
+|                                                             |
+|                                              Hypervisor     |
+|                                              Debian 8       |
+|                                              Kernel 3.16    |
++-------------------------------------------------------------+
+
+Steps
+=====
+
+1. Start a DPDK application using virtio ports
+2. Send traffic over those ports (using ping flood ...)
+3. Kill this DPDK application (sending SIGKILL, making it crash etc...)
+4. Restart this DPDK application with the same configuration
+5. During EAL initialization, if an incoming packet is received on a virtio
+   port, qemu exits (error code 1) with the following message:
+> qemu-system-x86_64: Guest moved used index from 571 to 0
+
+NOTE: This issue is *NOT* seen with e1000 interface
+
+Configuration
+=============
+
+Hypervisor
+-----------
+Debian 8
+Kernel 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
+
+Qemu
+----
+
+qemu 2.5 (vanilla)
+./configure --enable-kvm --enable-vhost-net --enable-vde --target-list="x86_64-softmmu" --enable-debug --extra-cflags="-O0 -g"
+
+> qemu-system-x86_64 -k fr --enable-kvm -m 4G -cpu host -smp \
+  sockets=1,cores=1,threads=2 -serial telnet::46528,server,nowait -serial null \
+  -qmp tcp::47257,server,nowait -monitor telnet::59305,server,nowait  -hda \
+  "/opt/vm/ubuntu-14.04-template.qcow2" -snapshot -vga none -display none \
+  -netdev vde,id=tapdeed01417a99,sock=L.vdesock -device \
+  virtio-net,mac=DE:ED:01:0C:DD:CC,addr=04,netdev=tapdeed01417a99 -netdev \
+  vde,id=tapdeed021a7b37,sock=R.vdesock -device \
+  virtio-net,mac=DE:ED:02:04:01:60,addr=05,netdev=tapdeed021a7b37
+
+On Testnode
+-----------
+
+Configure interface to send continuous traffic to PMD
+> ip link set dev eth0 up
+> ip addr add 1.1.1.1/24 dev eth0
+> ip neigh add 1.1.1.2 lladdr DE:ED:01:0C:DD:CC dev eth0
+> ping -q -f 1.1.1.2
+
+On DUT
+------
+
+Configure and start testpmd (a standard DPDK application)
+
+> modprobe uio
+> modprobe igb_uio
+> mkdir -p /mnt/huge
+> mount -t hugetlbfs nodev /mnt/huge
+> echo 64 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
+> dpdk_nic_bind  --bind=igb_uio 0000:00:04.0
+> dpdk_nic_bind  --bind=igb_uio 0000:00:05.0
+> testpmd --huge-dir=/mnt/huge -n 4 -l 0-1 --socket-mem 128 -w 0000:00:04.0 \
+  -w 0000:00:05.0 --log-level 8 -- -i --nb-cores=1 --nb-ports=2\
+  --total-num-mbufs=1025
+EAL: Detected lcore 0 as core 0 on socket 0
+EAL: Detected lcore 1 as core 0 on socket 0
+EAL: Support maximum 255 logical core(s) by configuration.
+EAL: Detected 2 lcore(s)
+EAL: Probing VFIO support...
+EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory)
+EAL: VFIO modules not loaded, skipping VFIO support...
+EAL: Setting up physically contiguous memory...
+EAL: Ask a virtual area of 0x4600000 bytes
+EAL: Virtual area found at 0x7fbcbf000000 (size = 0x4600000)
+EAL: Ask a virtual area of 0xc00000 bytes
+EAL: Virtual area found at 0x7fbcbe200000 (size = 0xc00000)
+EAL: Ask a virtual area of 0x400000 bytes
+EAL: Virtual area found at 0x7fbcbdc00000 (size = 0x400000)
+EAL: Ask a virtual area of 0x200000 bytes
+EAL: Virtual area found at 0x7fbcbd800000 (size = 0x200000)
+EAL: Ask a virtual area of 0x200000 bytes
+EAL: Virtual area found at 0x7fbcbd400000 (size = 0x200000)
+EAL: Ask a virtual area of 0x1c00000 bytes
+EAL: Virtual area found at 0x7fbcbb600000 (size = 0x1c00000)
+EAL: Ask a virtual area of 0x600000 bytes
+EAL: Virtual area found at 0x7fbcbae00000 (size = 0x600000)
+EAL: Ask a virtual area of 0x200000 bytes
+EAL: Virtual area found at 0x7fbcbaa00000 (size = 0x200000)
+EAL: Ask a virtual area of 0x200000 bytes
+EAL: Virtual area found at 0x7fbcba600000 (size = 0x200000)
+EAL: Requesting 64 pages of size 2MB from socket 0
+EAL: TSC frequency is ~3192572 KHz
+EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles !
+EAL: Master lcore 0 is ready (tid=c5707900;cpuset=[0])
+EAL: lcore 1 is ready (tid=c3ffd700;cpuset=[1])
+EAL: PCI device 0000:00:04.0 on NUMA socket -1
+EAL:   probe driver: 1af4:1000 rte_virtio_pmd
+EAL:   PCI memory mapped at 0x7fbcc3600000
+PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11
+PMD: virtio_read_caps(): no modern virtio pci device found.
+PMD: vtpci_init(): trying with legacy virtio pci.
+PMD: virtio_resource_init_by_uio(): PCI Port IO found start=0xc020 with size=0x20
+PMD: virtio_negotiate_features(): guest_features before negotiate = 100cf8020
+PMD: virtio_negotiate_features(): host_features before negotiate = 79bf8064
+PMD: virtio_negotiate_features(): features after negotiate = 8f8020
+PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:01:0C:DD:CC
+PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported
+PMD: virtio_dev_cq_queue_setup():  >>
+PMD: virtio_dev_queue_setup(): setting up queue: 2
+PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0
+PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192
+PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:      0x134f35000
+PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaf35000
+PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1
+PMD: eth_virtio_dev_init(): config->status=1
+PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:01:0C:DD:CC
+PMD: eth_virtio_dev_init(): hw->max_rx_queues=1   hw->max_tx_queues=1
+PMD: eth_virtio_dev_init(): port 0 vendorID=0x1af4 deviceID=0x1000
+PMD: virtio_dev_vring_start():  >>
+PMD: virtio_dev_cq_start(): VQ: - size=64; free=64; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+EAL: PCI device 0000:00:05.0 on NUMA socket -1
+EAL:   probe driver: 1af4:1000 rte_virtio_pmd
+EAL:   PCI memory mapped at 0x7fbcc3601000
+PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11
+PMD: virtio_read_caps(): no modern virtio pci device found.
+PMD: vtpci_init(): trying with legacy virtio pci.
+PMD: virtio_resource_init_by_uio(): PCI Port IO found start=0xc040 with size=0x20
+PMD: virtio_negotiate_features(): guest_features before negotiate = 100cf8020
+PMD: virtio_negotiate_features(): host_features before negotiate = 79bf8064
+PMD: virtio_negotiate_features(): features after negotiate = 8f8020
+PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:02:04:01:60
+PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported
+PMD: virtio_dev_cq_queue_setup():  >>
+PMD: virtio_dev_queue_setup(): setting up queue: 2
+PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0
+PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192
+PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:      0x134f30000
+PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaf30000
+PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1
+PMD: eth_virtio_dev_init(): config->status=1
+PMD: eth_virtio_dev_init(): PORT MAC: DE:ED:02:04:01:60
+PMD: eth_virtio_dev_init(): hw->max_rx_queues=1   hw->max_tx_queues=1
+PMD: eth_virtio_dev_init(): port 1 vendorID=0x1af4 deviceID=0x1000
+PMD: virtio_dev_vring_start():  >>
+PMD: virtio_dev_cq_start(): VQ: - size=64; free=64; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+Interactive-mode selected
+Configuring Port 0 (socket 0)
+PMD: virtio_dev_configure(): configure
+PMD: virtio_dev_tx_queue_setup():  >>
+PMD: virtio_dev_queue_setup(): setting up queue: 1
+PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:512
+PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288
+PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:      0x134eac000
+PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaeac000
+PMD: virtio_dev_rx_queue_setup():  >>
+PMD: virtio_dev_queue_setup(): setting up queue: 0
+PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:128
+PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288
+PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:      0x134ea6000
+PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaea6000
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 0 is up
+PMD: virtio_dev_rxtx_start():  >>
+PMD: virtio_dev_vring_start():  >>
+PMD: virtio_dev_vring_start(): Allocated 256 bufs
+PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+PMD: virtio_dev_vring_start():  >>
+PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+PMD: virtio_dev_start(): nb_queues=1
+PMD: virtio_dev_start(): Notified backend at initialization
+PMD: virtio_dev_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+PMD: virtio_dev_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+rte_eth_dev_config_restore: port 0: MAC address array not supported
+PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880
+PMD: virtio_send_command(): vq->vq_queue_index = 2
+PMD: virtio_send_command(): vq->vq_free_cnt=64
+vq->vq_desc_head_idx=0
+PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880
+PMD: virtio_send_command(): vq->vq_queue_index = 2
+PMD: virtio_send_command(): vq->vq_free_cnt=64
+vq->vq_desc_head_idx=0
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 0 is up
+Port 0: DE:ED:01:0C:DD:CC
+Configuring Port 1 (socket 0)
+PMD: virtio_dev_configure(): configure
+PMD: virtio_dev_tx_queue_setup():  >>
+PMD: virtio_dev_queue_setup(): setting up queue: 1
+PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:512
+PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288
+PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:      0x134ea1000
+PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbaea1000
+PMD: virtio_dev_rx_queue_setup():  >>
+PMD: virtio_dev_queue_setup(): setting up queue: 0
+PMD: virtio_dev_queue_setup(): vq_size: 256 nb_desc:128
+PMD: virtio_dev_queue_setup(): vring_size: 10244, rounded_vring_size: 12288
+PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:      0x134e9c000
+PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fbcbae9c000
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 1 is up
+PMD: virtio_dev_rxtx_start():  >>
+PMD: virtio_dev_vring_start():  >>
+PMD: virtio_dev_vring_start(): Allocated 256 bufs
+PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+PMD: virtio_dev_vring_start():  >>
+PMD: virtio_dev_rxtx_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+PMD: virtio_dev_start(): nb_queues=1
+PMD: virtio_dev_start(): Notified backend at initialization
+PMD: virtio_dev_start(): VQ: - size=256; free=0; used=0; desc_head_idx=32768; avail.idx=256; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+PMD: virtio_dev_start(): VQ: - size=256; free=256; used=0; desc_head_idx=0; avail.idx=0; used_cons_idx=0; used.idx=0; avail.flags=0x1; used.flags=0x0
+rte_eth_dev_config_restore: port 1: MAC address array not supported
+PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0
+PMD: virtio_send_command(): vq->vq_queue_index = 2
+PMD: virtio_send_command(): vq->vq_free_cnt=64
+vq->vq_desc_head_idx=0
+PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0
+PMD: virtio_send_command(): vq->vq_queue_index = 2
+PMD: virtio_send_command(): vq->vq_free_cnt=64
+vq->vq_desc_head_idx=0
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 1 is up
+Port 1: DE:ED:02:04:01:60
+Checking link statuses...
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 0 is up
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 1 is up
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 0 is up
+Port 0 Link Up - speed 10000 Mbps - full-duplex
+PMD: virtio_dev_link_update(): Get link status from hw
+PMD: virtio_dev_link_update(): Port 1 is up
+Port 1 Link Up - speed 10000 Mbps - full-duplex
+Done
+PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf37880 vq = 0x7fbcbaf37880
+PMD: virtio_send_command(): vq->vq_queue_index = 2
+PMD: virtio_send_command(): vq->vq_free_cnt=64
+vq->vq_desc_head_idx=0
+PMD: virtio_send_command(): vq->vq_desc_head_idx = 0, status = 255, vq->hw->cvq = 0x7fbcbaf325c0 vq = 0x7fbcbaf325c0
+PMD: virtio_send_command(): vq->vq_queue_index = 2
+PMD: virtio_send_command(): vq->vq_free_cnt=64
+vq->vq_desc_head_idx=0
+testpmd> start
+  io packet forwarding - CRC stripping disabled - packets/burst=32
+  nb forwarding cores=1 - nb forwarding ports=2
+  RX queues=1 - RX desc=128 - RX free threshold=0
+  RX threshold registers: pthresh=0 hthresh=0 wthresh=0
+  TX queues=1 - TX desc=512 - TX free threshold=0
+  TX threshold registers: pthresh=0 hthresh=0 wthresh=0
+  TX RS bit threshold=0 - TXQ flags=0xf00
+
+...
+[wait a few seconds]
+...
+
+Kill the application
+> kill -9 $(pidof testpmd) (On another shell)
+
+Relaunch the application
+> testpmd --huge-dir=/mnt/huge -n 4 -l 0-1 --socket-mem 128 -w 0000:00:04.0 \
+  -w 0000:00:05.0 --log-level 8 -- -i --nb-cores=1 --nb-ports=2 \
+  --total-num-mbufs=1025
+EAL: Detected lcore 0 as core 0 on socket 0
+EAL: Detected lcore 1 as core 0 on socket 0
+EAL: Support maximum 255 logical core(s) by configuration.
+EAL: Detected 2 lcore(s)
+EAL: Probing VFIO support...
+EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory)
+EAL: VFIO modules not loaded, skipping VFIO support...
+EAL: Setting up physically contiguous memory...
+EAL: Ask a virtual area of 0x4400000 bytes
+EAL: Virtual area found at 0x7f86cde00000 (size = 0x4400000)
+EAL: Ask a virtual area of 0x400000 bytes
+EAL: Virtual area found at 0x7f86cd800000 (size = 0x400000)
+EAL: Ask a virtual area of 0x400000 bytes
+EAL: Virtual area found at 0x7f86cd200000 (size = 0x400000)
+EAL: Ask a virtual area of 0x200000 bytes
+EAL: Virtual area found at 0x7f86cce00000 (size = 0x200000)
+EAL: Ask a virtual area of 0xc00000 bytes
+EAL: Virtual area found at 0x7f86cc000000 (size = 0xc00000)
+EAL: Ask a virtual area of 0x1c00000 bytes
+EAL: Virtual area found at 0x7f86ca200000 (size = 0x1c00000)
+EAL: Ask a virtual area of 0x600000 bytes
+EAL: Virtual area found at 0x7f86c9a00000 (size = 0x600000)
+EAL: Ask a virtual area of 0x400000 bytes
+EAL: Virtual area found at 0x7f86c9400000 (size = 0x400000)
+EAL: Requesting 64 pages of size 2MB from socket 0
+...
+
+VM has been killed by qemu with the following error
+> qemu-system-x86_64: Guest moved used index from 570 to 0
+
+Debugging
+---------
+
+With GDB, I have got this backtrace for Qemu
+
+(gdb) bt full
+#0  __GI_exit (status=1) at exit.c:104
+No locals.
+#1  0x00007f13cb53412e in virtqueue_num_heads (vq=0x7f13ce28d4c0, idx=592)
+    at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:320
+        num_heads = 64944
+#2  0x00007f13cb53444e in virtqueue_get_avail_bytes (vq=0x7f13ce28d4c0, in_bytes=0x7fff5c036270, 
+    out_bytes=0x7fff5c036274, max_in_bytes=110, max_out_bytes=0) at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:381
+        idx = 592
+        total_bufs = 0
+        in_total = 0
+        out_total = 0
+#3  0x00007f13cb5344b6 in virtqueue_avail_bytes (vq=0x7f13ce28d4c0, in_bytes=110, out_bytes=0)
+    at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:447
+        in_total = 1543725744
+        out_total = 32767
+#4  0x00007f13cb51ad6b in virtio_net_has_buffers (q=0x7f13ce22cea0, bufsize=110)
+    at /tmp/qemu/qemu-2.5.0/hw/net/virtio-net.c:899
+        n = 0x7f13cda08f18
+#5  0x00007f13cb51b37d in virtio_net_receive (nc=0x7f13cdf96490, 
+    buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98)
+    at /tmp/qemu/qemu-2.5.0/hw/net/virtio-net.c:1037
+        n = 0x7f13cda08f18
+        q = 0x7f13ce22cea0
+        vdev = 0x7f13cda08f18
+        __func__ = "virtio_net_receive"
+        mhdr_sg = {{iov_base = 0x7f1365fda43e, iov_len = 2}, {iov_base = 0x0, iov_len = 0} <repeats 1023 times>}
+        mhdr = {hdr = {flags = 0 '\000', gso_type = 0 '\000', hdr_len = 0, gso_size = 0, csum_start = 0, 
+            csum_offset = 0}, num_buffers = 1}
+        mhdr_cnt = 0
+        offset = 98
+        i = 1
+        guest_offset = 12
+        __PRETTY_FUNCTION__ = "virtio_net_receive"
+#6  0x00007f13cb75da86 in nc_sendv_compat (nc=0x7f13cdf96490, iov=0x7fff5c057440, iovcnt=1, flags=0) at net/net.c:717
+        buf = '\000' <repeats 416 times>...
+        buffer = 0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b"
+        offset = 98
+#7  0x00007f13cb75db3e in qemu_deliver_packet_iov (sender=0x7f13cc902eb0, flags=0, iov=0x7fff5c057440, iovcnt=1, 
+    opaque=0x7f13cdf96490) at net/net.c:741
+        nc = 0x7f13cdf96490
+        ret = 0
+#8  0x00007f13cb75fa5f in qemu_net_queue_deliver (queue=0x7f13cdf966b0, sender=0x7f13cc902eb0, flags=0, 
+    data=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) at net/queue.c:163
+        ret = -1
+        iov = {iov_base = 0x7fff5c057580, iov_len = 98}
+#9  0x00007f13cb75fb7b in qemu_net_queue_send (queue=0x7f13cdf966b0, sender=0x7f13cc902eb0, flags=0, 
+    data=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/queue.c:198
+        ret = 139722994604174
+#10 0x00007f13cb75d8d9 in qemu_send_packet_async_with_flags (sender=0x7f13cc902eb0, flags=0, 
+    buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/net.c:677
+        queue = 0x7f13cdf966b0
+        ret = 0
+#11 0x00007f13cb75d911 in qemu_send_packet_async (sender=0x7f13cc902eb0, 
+    buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98, sent_cb=0x0) at net/net.c:684
+No locals.
+#12 0x00007f13cb75d93e in qemu_send_packet (nc=0x7f13cc902eb0, 
+    buf=0x7fff5c057580 "\336\355\001\246\223t\336\355\001\211\371\360\b", size=98) at net/net.c:690
+No locals.
+#13 0x00007f13cb76b49e in vde_to_qemu (opaque=0x7f13cc902eb0) at net/vde.c:47
+        s = 0x7f13cc902eb0
+        buf = "[...]"
+        size = 98
+[...]
+
+According to GDB, there is no available vring
+(gdb) up
+#1  0x00007f13cb53412e in virtqueue_num_heads (vq=0x7f13ce28d4c0, idx=592)
+    at /tmp/qemu/qemu-2.5.0/hw/virtio/virtio.c:320
+320	        exit(1);
+(gdb) p num_heads
+$1 = 64944
+(gdb) p vq->vring.num
+$2 = 256
+(gdb) p idx
+$3 = 592
+(gdb) p vring_avail_idx(vq)
+$5 = 0
+
+VMs network topology
+
+On Wed, Mar 16, 2016 at 05:22:07PM -0000, Julien Meunier wrote:
+> I ran a DPDK application with virtio ports. If I killed and relaunched it, VM is
+> killed by qemu with the following message:
+> > qemu-system-x86_64: Guest moved used index from 571 to 0
+> 
+> If I ran the same application with e1000 ports, I haven't this issue.
+> 
+> Network topology
+> ================
+> 
+> I used two VM machines with last qemu-2.5 with two virtio-net netdevs. Both
+> netdevs are connected through a VDE switch.
+> 
+> On testnode, I used a Debian 8 (3.16) and virtio-net linux drivers. On DUT, I
+> used a Ubuntu 14.04 (3.13) with DPDK (next/16_04) with virtio pmd.
+> 
+> (Topology in attachment, launchpad does not support ascii-art)
+> 
+> Steps
+> =====
+> 
+> 1. Start a DPDK application using virtio ports
+> 2. Send traffic over those ports (using ping flood ...)
+> 3. Kill this DPDK application (sending SIGKILL, making it crash etc...)
+> 4. Restart this DPDK application with the same configuration
+> 5. During EAL initialization, if an incoming packet is received on a virtio
+>    port, qemu exits (error code 1) with the following message:
+> > qemu-system-x86_64: Guest moved used index from 571 to 0
+
+The DPDK application is not using the virtio-net device correctly.  QEMU
+will abort if the driver (application) is out of sync with the device.
+
+The application probably needs to do an explicit virtio device reset in
+order to reinitialize the vrings.
+
+This ungraceful exit isn't pretty but it is shows there is a bug with
+the driver.  Please contact the application authors to fix the
+application (it must reset the device explicitly to initialize it).
+
+Stefan
+
+
+Stefan, I too had the same immediate idea upon seeing this bug report. But, after I skimmed the DPDK code briefly, I think it does reset the virtio-net device correctly, before it tries to use it.
+
+Instead, at least based on the extensive log that Julien pasted, I believe the following happens: when the first instance of testpmd is killed ungracefully, it gets no chance at resetting the virtio-net device at shutdown. The vtpci_reset() call in virtio_dev_close() is likely never reached. This leaves the virtio queues alive, as far as QEMU is concerned, but in the guest, the memory that used to cover them goes away.
+
+So when the second instance of testpmd is started, and a bunch of memory is allocated and written to, I think testpmd scribbles over the "leftover" live virtio queues that QEMU / KVM are still watching. The hypervisor is allowed to notice changes to the virtqueues without explicit guest notifications (hence the elaborate barrier stuff in the Linux kernel drivers, for example). I suspect things blow up before the second testpmd process even thinks about using virtio-net. (It is hard to confirm from the log that Julien pasted, because he snipped exactly the part that leads up to the failure.)
+
+This failure mode (if my hunch is correct) is special to DPDK, I think. In a normal guest kernel scenario, the memory that covers the virtqueues is managed by the kernel, and you can't just kill the kernel. You might be able to unload the virtio-net driver module, but for that one has to tear down the corresponding ethX interfaces first, and I'm quite sure the virtio-net devices will be re-set then.
+
+We've seen the exact same problem with iPXE (in UEFI guests) as well, when iPXE would transfer control to the kernel or another payload; but iPXE got fixed: it now disconnects the virtio-net NIC (and other NICs too) in the ExitBootServices() callback. (I'm not perfectly happy with that fix for unrelated reasons, but it definitely covers this issue.)
+
+OVMF too resets virtio devices in the ExitBootServices() callbacks of its virtio drivers. So this failure mode seems to be special to DPDK, where you can kill the testpmd process and deprive it from the chance to clean up the virtqueues (by resetting the device).
+
+(The iPXE commit in question is 755d2b8f6be6.)
+
+(Bugfix for a similar SeaBIOS bug: 5f2d17d35b23.)
+
+On Thu, Mar 17, 2016 at 03:56:42PM -0000, Laszlo Ersek (Red Hat) wrote:
+> Stefan, I too had the same immediate idea upon seeing this bug report.
+> But, after I skimmed the DPDK code briefly, I think it does reset the
+> virtio-net device correctly, before it tries to use it.
+> 
+> Instead, at least based on the extensive log that Julien pasted, I
+> believe the following happens: when the first instance of testpmd is
+> killed ungracefully, it gets no chance at resetting the virtio-net
+> device at shutdown. The vtpci_reset() call in virtio_dev_close() is
+> likely never reached. This leaves the virtio queues alive, as far as
+> QEMU is concerned, but in the guest, the memory that used to cover them
+> goes away.
+> 
+> So when the second instance of testpmd is started, and a bunch of memory
+> is allocated and written to, I think testpmd scribbles over the
+> "leftover" live virtio queues that QEMU / KVM are still watching. The
+> hypervisor is allowed to notice changes to the virtqueues without
+> explicit guest notifications (hence the elaborate barrier stuff in the
+> Linux kernel drivers, for example). I suspect things blow up before the
+> second testpmd process even thinks about using virtio-net. (It is hard
+> to confirm from the log that Julien pasted, because he snipped exactly
+> the part that leads up to the failure.)
+> 
+> This failure mode (if my hunch is correct) is special to DPDK, I think.
+> In a normal guest kernel scenario, the memory that covers the virtqueues
+> is managed by the kernel, and you can't just kill the kernel. You might
+> be able to unload the virtio-net driver module, but for that one has to
+> tear down the corresponding ethX interfaces first, and I'm quite sure
+> the virtio-net devices will be re-set then.
+> 
+> We've seen the exact same problem with iPXE (in UEFI guests) as well,
+> when iPXE would transfer control to the kernel or another payload; but
+> iPXE got fixed: it now disconnects the virtio-net NIC (and other NICs
+> too) in the ExitBootServices() callback. (I'm not perfectly happy with
+> that fix for unrelated reasons, but it definitely covers this issue.)
+> 
+> OVMF too resets virtio devices in the ExitBootServices() callbacks of
+> its virtio drivers. So this failure mode seems to be special to DPDK,
+> where you can kill the testpmd process and deprive it from the chance to
+> clean up the virtqueues (by resetting the device).
+
+QEMU can and should help by making this a non-fatal error: treat the
+device as broken when an invalid state is reached and stop processing
+virtqueues until it is reset.  Fatal errors in QEMU device emulation are
+a bad thing.
+
+However, it's still a guest code bug because a driver must not abandon
+an active device.  Depending on the contents of the rings it could cause
+spurious I/O leading to data corruption.
+
+So this needs to be fixed in DPDK or the application.
+
+Stefan
+
+
+You are right, this failure is special to DPDK. An upstream patch has been purposed few hours after I did my tests... http://dpdk.org/browse/dpdk/commit/?id=9a0615af774648
+
+With this patch, at each start of a DPDK application,  virtio_dev_close is now always called, in order to (re)-initialize properly a virtio device.
+
+Thanks for yours explanations and details.
+
+On 03/18/16 10:45, Stefan Hajnoczi wrote:
+
+> However, it's still a guest code bug because a driver must not abandon
+> an active device.  Depending on the contents of the rings it could cause
+> spurious I/O leading to data corruption.
+> 
+> So this needs to be fixed in DPDK or the application.
+
+I agree.
+
+Laszlo
+
+
+
+Closing this ticket since it was a bug in DPDK, and not in QEMU.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1568 b/results/classifier/zero-shot/118/peripherals/1568
new file mode 100644
index 00000000..ce151a07
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1568
@@ -0,0 +1,69 @@
+peripherals: 0.888
+arm: 0.870
+KVM: 0.865
+architecture: 0.861
+performance: 0.855
+device: 0.854
+assembly: 0.850
+debug: 0.848
+kernel: 0.847
+graphic: 0.843
+semantic: 0.843
+hypervisor: 0.827
+PID: 0.822
+boot: 0.811
+VMM: 0.798
+register: 0.793
+virtual: 0.792
+mistranslation: 0.759
+permissions: 0.758
+socket: 0.750
+vnc: 0.742
+user-level: 0.725
+ppc: 0.719
+risc-v: 0.717
+TCG: 0.695
+x86: 0.685
+i386: 0.660
+network: 0.651
+files: 0.596
+
+qemu-system-m68k fails whenever the option "-d cpu_reset" is specified
+Description of problem:
+When specifying the option "-d cpu_reset", the following output is generated, and QEMU eventually crashes with a Segmentation fault:
+```
+CPU Reset (CPU 0)
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+PC = 00000000   qemu: fatal: Bad CC_OP 0
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+...
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+PC = 00000000   qemu: fatal: Bad CC_OP 0
+Segmentation fault (core dumped)
+```
+This also happens with the other m68k machine types.
+Steps to reproduce:
+1. Run QEMU with the given command line.
+Additional information:
+
diff --git a/results/classifier/zero-shot/118/peripherals/157 b/results/classifier/zero-shot/118/peripherals/157
new file mode 100644
index 00000000..b534d99b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/157
@@ -0,0 +1,31 @@
+peripherals: 0.989
+device: 0.930
+performance: 0.778
+risc-v: 0.486
+arm: 0.471
+ppc: 0.465
+socket: 0.443
+VMM: 0.428
+register: 0.413
+graphic: 0.412
+semantic: 0.352
+debug: 0.345
+vnc: 0.297
+mistranslation: 0.269
+permissions: 0.257
+boot: 0.245
+user-level: 0.206
+PID: 0.190
+architecture: 0.174
+virtual: 0.126
+TCG: 0.094
+network: 0.093
+i386: 0.073
+assembly: 0.043
+KVM: 0.040
+kernel: 0.025
+hypervisor: 0.020
+files: 0.019
+x86: 0.005
+
+Xbox One controller USB passthrough disconnections and stops
diff --git a/results/classifier/zero-shot/118/peripherals/1585008 b/results/classifier/zero-shot/118/peripherals/1585008
new file mode 100644
index 00000000..b00d7cab
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1585008
@@ -0,0 +1,81 @@
+peripherals: 0.866
+socket: 0.846
+graphic: 0.838
+register: 0.822
+device: 0.822
+permissions: 0.813
+boot: 0.805
+semantic: 0.776
+files: 0.760
+PID: 0.748
+virtual: 0.742
+architecture: 0.740
+hypervisor: 0.721
+user-level: 0.719
+risc-v: 0.717
+assembly: 0.716
+arm: 0.716
+ppc: 0.696
+debug: 0.694
+network: 0.674
+performance: 0.656
+vnc: 0.609
+kernel: 0.586
+TCG: 0.580
+VMM: 0.573
+KVM: 0.560
+mistranslation: 0.490
+x86: 0.438
+i386: 0.365
+
+Windows 7 guests hang on bootup when qxl video is used
+
+I installed libvirt-bin and virt-manager on Ubuntu 16.04.  I created a new VM for Windows 7, basically with default settings, which includes qxl video..  The Windows boot process hangs with the "Starting Windows" animation.  CPU and disk I/O drop to zero, and it continues animating.... forever and ever...  It never finishes booting.  But it doesn't fully "hang" either: the animation continues to animate.
+
+As a workaround, I set the video mode to "Cirrus" and then Windows boots but it is slow and limited.  And also apparently to be avoided:
+
+https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
+
+I can confirm it's only when qxl is enabled, because if I switch from Cirrus back to qxl, it hangs again - and going back to Cirrus again "fixes" the problem.
+
+This issue is also reported elsewhere:
+
+http://serverfault.com/questions/776406/windows-7-setup-hangs-at-starting-windows-using-proxmox-4-2
+
+https://forum.proxmox.com/threads/win7-setup-hangs-in-proxmox-ve-4-2.27388/
+
+Hi,
+
+IUC this is not a bug in libvirt or virt-manager or qemu.  The problem
+is that windows 7 does not ship with the needed qxl drivers.  You need
+to download those and install them in the windows 7 guest.
+
+http://www.spice-space.org/download.html
+
+
+I also tested Windows Server 2012 R2 with UEFI / OVMF instead of BIOS.  This installed without issue with qxl.  The guest just used a generic display driver until I could install the qxl one built by Fedora project.
+
+Shouldn't the Windows 7 guest on BIOS behave the same way?  It's kind of hard to install display drivers when you *can't even boot the Windows setup DVD.*
+
+Or are you saying that, by design, qxl can't be used with clients that use generic VGA/VESA display modes? (but how did I get to the point of seeing BIOS load screen, and then "Starting Windows" which is certainly using some kind of VESA mode?)
+
+I'd like to point out that this bug is a regression. I previously installed Win 7 using qxl just as Mr Johnston installed W2012R2, and got the generic drivers until I was able to install qxl drivers. Neither qxl nor stdvga work any more, only cirrus, and that only seems to work under Seabios now, whereas it used to function under OVMF, yes even for Windows 7.  As I'm using Arch, and haven't reinstalled Windows 7 every day, I can't say when this bug appeared.  
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+@Anthony - are you saying this affects you under Arch?  (If so I'll mark it as affecting upstream qemu project)
+
+Yes, it's an upstream bug.  I've verified that it exists under an older version of OVMF, and also with the qemu command line, so it's a qemu or kernel thing, not libvirt or ovmf.
+
+Thanks.
+
+Downgraded to qemu-2.4.0-1 (on Arch), problem doesn't exist there.
+
+and doesn't exist in qemu-2.5.1-1; the next version I have in Arch is qemu-2.6.0-1, which is the current one where the problem exists.  So, something changed between 2.5 and 2.6
+
+Sorry about the multiple posts.
+
+This is a dupe of LP#1581936 and LP#1591724. The issue is fixed by upstream QEMU commit 94ef4f337fb6.
+
+Thanks - so it's fixed upstream and in ubuntu yakkety.  I'll mark it as a dup of bug 1591724.  
+
diff --git a/results/classifier/zero-shot/118/peripherals/1596009 b/results/classifier/zero-shot/118/peripherals/1596009
new file mode 100644
index 00000000..65ca8a2b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1596009
@@ -0,0 +1,70 @@
+peripherals: 0.861
+performance: 0.821
+semantic: 0.813
+architecture: 0.804
+graphic: 0.791
+device: 0.774
+debug: 0.766
+permissions: 0.734
+PID: 0.708
+register: 0.704
+x86: 0.697
+ppc: 0.695
+network: 0.693
+files: 0.689
+socket: 0.672
+vnc: 0.667
+assembly: 0.654
+user-level: 0.612
+arm: 0.600
+boot: 0.554
+virtual: 0.538
+hypervisor: 0.538
+TCG: 0.525
+mistranslation: 0.455
+kernel: 0.429
+VMM: 0.415
+risc-v: 0.406
+i386: 0.213
+KVM: 0.122
+
+config/build problem due to libncursesw on Xenial
+
+it happened to me during a build of yocto/bitbake related cross tools. the auto-configuration part titled "SDL probe" for qemu-2.2.0 i found the configuration step failing for the compile_prog routine. actually those test compile went fine but only the test linking failed.
+
+this was due a reference of the sub-sub-...-included libcaca referenced an initially not installed (hint: check for and report such pre-requisites upfront - might be yocto related) and later on installed by me component of name libncursesw seemingly in its dev variant (i was installing libncursesw5-dev_6.0+20160213-1ubuntu1_amd64.deb). tests on the command line showed that adding the required paths and resources made the test application link nicely.
+
+a quick hack attempt for the config script resulted in those line:
+  sdl_libs="$sdl_libs -L/lib/x86_64-linux-gnu -lncursesw"
+this allowed me to pass the configuration check nicely.
+i am just seeing my full scale compile fail for the same reason multiple times for linking. that all should be fixable the same way.
+
+you might or might not have addressed this in newer versions of your package. but you probably know that setups for embedded targets will sometimes lack behind in their evolution until a sudden (well prepared) some big jump in versions does happen. so i leave the hint here for your reference - for the main reason of this very often spotted message - raised by several main reasons according to public web reports, but not this one until right here and now:
+
+| ERROR: User requested feature sdl
+|        configure was not able to find it.
+|        Install SDL devel
+
+By the way these lines already have to locations in the configure script
+where the first indicates that pkg/sdl/sdl2-config application is not there (=no SDL devel there)
+whilst the second indicates that *-config is there but the test compile failed (=devel is broken for some other reason).
+This could/should see some improvement as well as this is the first hint on what went wrong - and in the second case you definitely can give the user the quite valueable hint for the log file with the results of the test compile.
+
+Could you please try to reproduce this problem with the latest release of QEMU (version 2.6)? Thanks!
+
+This is not an issue with Ubu but a Yocto build issue. In Xenial libsdl1.2-dev depends on libcaca-dev which depends on libcaca0 which depends on ncursesw5. Additionally libcaca.so is looking for symbols in libncursesw5 with variable decorations like `resize_term@NCURSESW_5.3.20021019', yet Yocto builds ncurses-native with the symbol decorations like 'resize_term@Base', thus the symbols aren't found when configure attempts to build a test application to check on SDL. So basically the above is describing a confusing web of who is providing what (host vs. Yocto -native) and what each library looks like internally.
+
+You can see these details better if you do something like:
+bitbake qemu -c devshell
+edit configure to add '-x' to the #! line
+run '../temp/run.do_configure'
+after the failure is displayed, cd ../build and run the gcc line from the failure msg
+
+To work around this you can force use of the host's ncurses library, so do something like this in your build's local.conf:
+
+ASSUME_PROVIDED += "libsdl-native ncurses-native"
+
+This is not a Ubu bug, so this issue should be closed.
+
+Closing according to comment #2.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1596204 b/results/classifier/zero-shot/118/peripherals/1596204
new file mode 100644
index 00000000..adcb77f1
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1596204
@@ -0,0 +1,56 @@
+peripherals: 0.895
+architecture: 0.554
+device: 0.551
+performance: 0.522
+kernel: 0.469
+graphic: 0.321
+semantic: 0.304
+debug: 0.303
+permissions: 0.293
+register: 0.288
+network: 0.270
+PID: 0.235
+i386: 0.223
+mistranslation: 0.221
+ppc: 0.220
+user-level: 0.183
+arm: 0.175
+x86: 0.171
+boot: 0.163
+socket: 0.161
+VMM: 0.146
+vnc: 0.134
+TCG: 0.051
+files: 0.048
+hypervisor: 0.047
+risc-v: 0.044
+assembly: 0.025
+KVM: 0.016
+virtual: 0.003
+
+UART problem in raspi2
+
+I was trying to run the raspberry pi uart example at https://github.com/dwelch67/raspberrypi/tree/master/uart01 using qemu 2.6.0, but it didn't work.
+
+The steps I took were:
+* Edit uart01/memmap and change origin to 0x10000 (which is the address qemu starts executing),
+* make
+* /usr/local/bin/qemu-system-arm -machine raspi2 -m 512M -nographic -gdb tcp::26000 -S -kernel uart01.bin
+
+Then start arm-none-eabi-gdb and run following commands:
+
+target remote localhost:26000
+symbol-file ./uart01.elf
+
+
+Then, when I start the program, it seems that the GET32(AUX_MU_LSR_REG)&0x20 condition never becomes true.
+
+This works on actual hardware, so I am wondering if I'm doing any steps incorrectly or missing.
+
+This is because you're running a binary for the raspberry pi 1 on a model of the raspberry pi 2. The peripherals are at different locations on the two boards, and so your program doesn't work. You can fix that by changing all the register addresses that start 0x20..... to 0x3f...., or more complicatedly by using the boards/cpuid/ code in that raspberrypi repo to detect the correct PBASE value to use.
+
+Secondly, the output goes to the second serial port, which in your command line is not being directed anywhere. You can put the second serial port's output on stdio with the first serial port output thrown away using '-serial null -serial stdio'. (For more complicated redirections, see the QEMU docs.)
+
+If I do those two things, then the uart01 example runs fine on QEMU.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1597 b/results/classifier/zero-shot/118/peripherals/1597
new file mode 100644
index 00000000..6b1b0bed
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1597
@@ -0,0 +1,86 @@
+peripherals: 0.883
+debug: 0.882
+KVM: 0.779
+architecture: 0.748
+performance: 0.740
+boot: 0.707
+kernel: 0.705
+device: 0.700
+socket: 0.611
+PID: 0.603
+ppc: 0.572
+semantic: 0.548
+graphic: 0.543
+VMM: 0.543
+files: 0.507
+vnc: 0.493
+virtual: 0.492
+register: 0.471
+arm: 0.470
+assembly: 0.450
+TCG: 0.425
+hypervisor: 0.419
+risc-v: 0.377
+permissions: 0.349
+x86: 0.331
+user-level: 0.326
+mistranslation: 0.317
+i386: 0.281
+network: 0.271
+
+Intel Arc A-Series GPUs VFIO passthrough no video out
+Description of problem:
+Once the VM is booted, the screen goes blank.
+Steps to reproduce:
+1. Passthough any Intel Arc A (Alchemist) series video card.
+2. Boot VM.
+3. Screen goes blank.
+Additional information:
+I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I start the VM that issue presents itself.
+
+
+
+kernel command line:
+
+```
+amd_iommu=on iommu=pt rd.driver.pre=vfio-pci pci=realloc iommu=1 i915.force_probe=*
+
+```
+
+startup script:
+
+```
+#!/bin/bash
+# Helpful to read output when debugging
+set -x
+
+# Load the config file with our environmental variables
+source "/etc/libvirt/hooks/kvm.conf"
+source "/etc/libvirt/hooks/vmPreBootSetup"
+
+cpuPerf
+
+# Stop your display manager. If you're on kde it'll be sddm.service. Gnome users should use 'killall gdm-x-session' instead
+systemctl stop gdm.service
+
+# Unbind VTconsoles
+echo 0 > /sys/class/vtconsole/vtcon0/bind
+echo 0 > /sys/class/vtconsole/vtcon1/bind
+
+# Avoid a race condition by waiting a couple of seconds. This can be calibrated to be shorter or longer if required for your system
+sleep 2
+
+modprobe -r drm_buddy intel_gtt video drm_display_helper cec ttm i915
+
+# Unbind the GPU from display driver
+virsh nodedev-detach $VIRSH_GPU_VIDEO
+virsh nodedev-detach $VIRSH_GPU_AUDIO
+
+# Load VFIO kernel module
+modprobe vfio
+modprobe vfio_pci
+modprobe vfio_iommu_type1
+
+sleep 5s ; systemctl restart connman.service
+
+```
diff --git a/results/classifier/zero-shot/118/peripherals/1634852 b/results/classifier/zero-shot/118/peripherals/1634852
new file mode 100644
index 00000000..aeef5dc4
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1634852
@@ -0,0 +1,79 @@
+peripherals: 0.969
+architecture: 0.951
+kernel: 0.941
+x86: 0.931
+device: 0.929
+hypervisor: 0.918
+performance: 0.899
+network: 0.886
+ppc: 0.877
+PID: 0.870
+register: 0.861
+graphic: 0.843
+user-level: 0.841
+permissions: 0.835
+VMM: 0.834
+risc-v: 0.816
+files: 0.796
+socket: 0.787
+vnc: 0.782
+KVM: 0.777
+arm: 0.768
+TCG: 0.731
+debug: 0.730
+virtual: 0.705
+i386: 0.685
+mistranslation: 0.654
+boot: 0.652
+assembly: 0.551
+semantic: 0.443
+
+Qemu VirtFS mounts are not accessible after resuming guest from hibernation
+
+Host OS:  Funtoo Linux
+Host Kernel:  4.7.4-gentoo
+Qemu Version:  2.7.0
+Guest OS:  Ubuntu 14.04
+Guest Kernel:  reproduced with both 4.4.0-42-generic and 3.13.0-98-generic
+
+Qemu command line:
+
+qemu-system-x86_64 \
+    -machine type=pc,accel=kvm \
+    -cpu host \
+    -smp 3 \
+    -m 8G \
+    -netdev bridge,id=hn0,vhost=on \
+    -device virtio-net-pci,netdev=hn0,mac=52:54:fa:70:35:f7 \
+    -drive file=/dev/mapper/vg-ubuntu,format=raw,if=virtio,cache=none,discard=on \
+    -virtfs local,path=/home/dharding/code,security_model=passthrough,mount_tag=code \
+    -virtfs local,path=/home/dharding/xfer,security_model=passthrough,mount_tag=xfer \
+    -display gtk
+
+
+Relevant lines from guest /etc/fstab:
+code /home/dharding/code 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0
+xfer /home/dharding/xfer 9p trans=virtio,version=9p2000.L,msize=262144,_netdev 0 0
+
+
+Steps to reproduce:
+- start qemu using the above command line
+- in the guest, run "sudo pm-hibernate"
+- after qemu exits, run again using the same command line
+- once the guest resumes from hibernation, run "ls /home/dharding/code"
+- the ls command will hang forever
+
+The ls call stack is:
+
+[<ffffffffc00743a0>] p9_client_rpc+0x110/0x460 [9pnet]
+[<ffffffffc0076a50>] p9_client_getattr_dotl+0x60/0x160 [9pnet]
+[<ffffffffc009ef77>] v9fs_vfs_getattr_dotl+0x47/0xa0 [9p]
+[<ffffffff81202a5c>] vfs_getattr_nosec+0x2c/0x40
+[<ffffffff81202b26>] vfs_getattr+0x26/0x30
+[<ffffffff81202bf5>] vfs_fstatat+0x65/0xa0
+[<ffffffff8120306f>] SYSC_newstat+0x1f/0x40
+[<ffffffff812032be>] SyS_newstat+0xe/0x10
+[<ffffffff817fa4f6>] entry_SYSCALL_64_fastpath+0x16/0x75
+
+The root cause lies in the 9pnet_virtio driver in the guest kernel: it does not support suspend/hibernation...
+
diff --git a/results/classifier/zero-shot/118/peripherals/1637693 b/results/classifier/zero-shot/118/peripherals/1637693
new file mode 100644
index 00000000..4521c6e3
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1637693
@@ -0,0 +1,83 @@
+peripherals: 0.866
+architecture: 0.831
+hypervisor: 0.789
+permissions: 0.785
+risc-v: 0.781
+device: 0.774
+user-level: 0.769
+KVM: 0.766
+debug: 0.759
+performance: 0.740
+register: 0.736
+boot: 0.733
+network: 0.728
+virtual: 0.724
+semantic: 0.723
+ppc: 0.719
+PID: 0.717
+x86: 0.710
+arm: 0.707
+assembly: 0.704
+files: 0.696
+TCG: 0.688
+mistranslation: 0.685
+graphic: 0.677
+VMM: 0.676
+vnc: 0.658
+socket: 0.629
+kernel: 0.602
+i386: 0.475
+
+QEMU not able to create vm with pflash and UEFI bios
+
+Running Fedora 24 with the virt-preview repo on QEMU Version 2.7.0 and libvirt version 2.2.0. Tried to install a windows 10 vm with the OVMF bios and this error happens every time, it didnt happen when using the stable version of qemu for fedora 24.
+
+libvirtError: internal error: qemu unexpectedly closed the monitor: 2016-10-29T04:07:29.678518Z qemu-system-x86_64: -drive file=/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on: oversized backing file, pflash segments cannot be mapped under 00000000ff800000
+
+Any ideas?
+
+Seems to work when using virt-install to do a manual uefi install
+
+This happens because the ArmVirtQemu firmware binary (== UEFI for aarch64 guests) is passed to qemu-system-x86_64.
+
+Normally such errors are not caught at QEMU startup time (similarly to the misconfiguration when you try to boot an aarch64 ISO in an x86_64 guest -- normally you would only notice the problem within the guest); however, in this case, the size of the ArmVirtQemu fw binary (64MB) is above the size that qemu-system-x86_64 permits for firmware binaries. (The pflash chip sizes and their limits are different per target.) That's why QEMU errs out early.
+
+I think this might be related to:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1295146
+https://www.redhat.com/archives/libvir-list/2016-October/msg00045.html
+
+I'll make the subscribers in that RHBZ aware of this issue.
+
+Zach if you can still reproduce, can you provide the libvirt XML and the associated qemu command line from /var/lib/libvirt/qemu/$VMNAME.log for the working (virt-install) config and the non-working (virt-manager) config?
+
+Hello Cole sorry i didnt get to you sooner, there doesnt seem to be a log anywhere in that specified area but here is the working xml https://u.teknik.io/hp3jG.xml. I did update everything to the latest version and it still does it (with the addition of a new thing where it says my cpu isnt compatible http://pastebin.com/5i7EdHza). I cant seem to find the virt-manager xml config/virt-install.
+
+This is all for PCI passthrough at the end of the day
+
+Alright found them sorry about that 
+Libvirt.conf : https://u.teknik.io/a0rWz.txt
+qemu.conf: https://u.teknik.io/5Gd3Q.txt
+
+Similar report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860363
+> This sounds like you are using the x86_64 architecture, but an aarch64 (arm64) firmware. Install ovmf (package in Debian) and use that as a firmware if your goal is to run an x86_64 OS.
+
+(Your /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw is for ARM aarch64, and qemu is x86_64 system, you can't run ARM firmware with x86_64 emulator)
+
+I had same "oversized backing file, pflash .." error message after installing qemu-efi package (https://packages.ubuntu.com/artful/qemu-efi) which is "UEFI firmware for 64-bit ARM virtual machines".
+
+It was fixed after purging qemu-efi (qemu-efi-aarch64) packages, installing ovmf package (https://packages.ubuntu.com/artful/ovmf) and restarting virt-manager.
+New virtual machine was created with correct UEFI firmware: /usr/share/OVMF/OVMF_CODE.fd
+
+My machine xml has line with /usr/share/OVMF/OVMF_CODE.fd
+<domain type='kvm'>
+...
+<os>
+...
+<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>"
+
+This should be solved by now, minimally by the firmware auto-selection feature. Regarding libvirt commits, see <https://bugzilla.redhat.com/show_bug.cgi?id=1564270#c6> and <https://bugzilla.redhat.com/show_bug.cgi?id=1564270#c9>. Regarding virt-manager commits, the latest related commit I can see is 15a9502b7b7a ("details: Fix showing the firmware type in case of firmware auto selection", 2020-01-15).
+
+
+Just a side note, once you tried to boot the vm with the wrong firmware, it will create an oversized nvram file that you must delete or else you will stil get the same error even after switching to the right firmware.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1643342 b/results/classifier/zero-shot/118/peripherals/1643342
new file mode 100644
index 00000000..65392c45
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1643342
@@ -0,0 +1,56 @@
+peripherals: 0.828
+x86: 0.792
+performance: 0.743
+device: 0.697
+files: 0.635
+virtual: 0.633
+semantic: 0.617
+graphic: 0.608
+architecture: 0.601
+boot: 0.563
+mistranslation: 0.540
+PID: 0.537
+ppc: 0.513
+VMM: 0.419
+KVM: 0.399
+socket: 0.389
+i386: 0.351
+user-level: 0.339
+debug: 0.310
+permissions: 0.288
+risc-v: 0.262
+TCG: 0.259
+vnc: 0.234
+kernel: 0.213
+register: 0.203
+network: 0.189
+assembly: 0.187
+hypervisor: 0.140
+arm: 0.094
+
+not able to passthrough mouse / keyboard
+
+After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm anymore. I get this error:
+
+qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device 'host:046d:c227'
+
+This happens with every usb-device I tried. Works 2.6.2 without any errors. (also tried in 2.7.0, same error)
+I use the following script:
+
+
+qemu-system-x86_64 \
+-enable-kvm \
+-m 16392 \
+-cpu host,kvm=off \
+-smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \
+-usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \
+-vga none \
+-device vfio-pci,host=01:00.0,multifunction=on \
+-device vfio-pci,host=01:00.1 \
+-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \
+-drive if=pflash,format=raw,file=/tmp/my_vars.fd \
+-device virtio-scsi-pci,id=scsi \
+-drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \
+-drive file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback -device scsi-hd,drive=disk \
+-drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw -device ide-cd,bus=ide.1,drive=virtiocd
+
diff --git a/results/classifier/zero-shot/118/peripherals/1653063 b/results/classifier/zero-shot/118/peripherals/1653063
new file mode 100644
index 00000000..e8db333d
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1653063
@@ -0,0 +1,99 @@
+peripherals: 0.809
+hypervisor: 0.801
+user-level: 0.781
+permissions: 0.777
+VMM: 0.754
+semantic: 0.751
+register: 0.746
+vnc: 0.726
+debug: 0.725
+assembly: 0.706
+KVM: 0.694
+graphic: 0.693
+virtual: 0.685
+ppc: 0.683
+mistranslation: 0.682
+PID: 0.681
+TCG: 0.674
+x86: 0.659
+network: 0.658
+arm: 0.658
+architecture: 0.655
+risc-v: 0.652
+i386: 0.619
+socket: 0.607
+device: 0.606
+boot: 0.598
+kernel: 0.597
+files: 0.557
+performance: 0.535
+
+qemu-system-arm hangs with -icount and -nodefaults
+
+I tested with the latest git repo, (commit: dbe2b65566e76d3c3a0c3358285c0336ac61e757).
+
+My configure options when building QEMU:
+'../configure' '--prefix=$HOME/local/qemu.git' '--target-list=aarch64-softmmu,arm-softmmu' '--cpu=x86_64' '--cc=gcc' '--disable-user' '--disable-sdl' '--disable-stack-protector' '--disable-attr' '--disable-pie' '--disable-linux-aio' '--disable-tpm' '--without-system-pixman' '--disable-docs' '--disable-guest-agent' '--disable-guest-agent-msi' '--disable-modules' '--disable-sparse' '--disable-gnutls' '--disable-nettle' '--disable-gcrypt' '--disable-gtk' '--disable-vte' '--disable-curses' '--disable-vnc' '--disable-cocoa' '--disable-virtfs' '--disable-xen' '--disable-brlapi' '--disable-curl' '--disable-bluez' '--disable-rdma' '--disable-uuid' '--disable-vde' '--disable-netmap' '--disable-cap-ng' '--disable-attr' '--disable-vhost-net' '--disable-spice' '--disable-rbd' '--disable-libiscsi' '--disable-libnfs' '--disable-smartcard' '--disable-libusb' '--disable-usb-redir' '--disable-lzo' '--disable-snappy' '--disable-bzip2' '--disable-seccomp' '--disable-glusterfs' '--disable-archipelago' '--disable-libssh2' '--disable-vhdx' '--disable-numa' '--disable-werror' '--disable-blobs' '--disable-vhost-scsi' '--enable-debug' '--disable-strip' '--enable-debug-tcg' '--enable-debug-info' '--extra-cflags=-fPIC'
+
+My host OS is Redhat RHEL-6.5. uname command gives:
+Linux rslpc1 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
+
+The test image is downloaded from http://wiki.qemu.org/download/arm-test-0.2.tar.gz
+
+The command to re-produce the problem:
+qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
+
+After console prints the message below:
+"Uncompressing Linux.......................................................................... done, booting the kernel."
+there's no further action noticed.
+
+If "-icount" is not set, namely run as:
+qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
+
+or if "-nodefaults" is not set, namely run as:
+qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0"
+
+The Linux boot procedure can finish successfully.
+
+Thanks.
+Hansni
+
+On Thu, Dec 29, 2016 at 5:04 AM, Andrew Jones <email address hidden> wrote:
+> On Thu, Dec 29, 2016 at 08:02:16AM -0000, Hansni Bu wrote:
+>> Public bug reported:
+> ...
+>> https://bugs.launchpad.net/bugs/1653063
+> ...
+>>   After console prints the message below:
+>>   "Uncompressing Linux.......................................................................... done, booting the kernel."
+>>   there's no further action noticed.
+>>
+>>   If "-icount" is not set, namely run as:
+>>   qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
+>>
+>>   or if "-nodefaults" is not set, namely run as:
+>>   qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0"
+>>
+>>   The Linux boot procedure can finish successfully.
+>
+> Hi Hansni,
+>
+> The fact things work when you remove -nodefaults is a sign that with it
+> your single cpu may just not be getting scheduled again. Does the patch
+> from Alex Bennée here[*] help?
+>
+> [*] https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01743.html
+>
+
+This bug is still reproducible with the latest git.
+
+--
+Pranith
+
+-- 
+Pranith
+
+
+I think we fixed this bug in commit 013aabdc665e4256b38d which would have been in the 3.1.0 release (this is why we closed #1774677, which is the same issue).
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1667613 b/results/classifier/zero-shot/118/peripherals/1667613
new file mode 100644
index 00000000..95d9421f
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1667613
@@ -0,0 +1,49 @@
+peripherals: 0.972
+graphic: 0.971
+ppc: 0.946
+device: 0.896
+architecture: 0.831
+user-level: 0.782
+semantic: 0.782
+PID: 0.703
+performance: 0.633
+mistranslation: 0.601
+register: 0.449
+vnc: 0.439
+network: 0.409
+arm: 0.403
+boot: 0.390
+debug: 0.383
+TCG: 0.348
+socket: 0.320
+permissions: 0.307
+risc-v: 0.285
+virtual: 0.269
+KVM: 0.263
+hypervisor: 0.201
+assembly: 0.191
+VMM: 0.184
+kernel: 0.160
+files: 0.111
+x86: 0.096
+i386: 0.038
+
+Qemu 2.8  on PPC64 issue with input
+
+Hi devs,
+on my PPC64 machine if i start qemu with gtk,gl=on or with sdl,gl=on i have issue with pointer and keyboard. pratically not input at all.
+This issue is present in tgc and in kvm
+
+without gl=on option in kvm with mate as guest i have the input device work in the beginning but after some time the usb goes "unplugged" (i see this message on the serial log of qemu usb unplugged) and the keyboard and mouse dont work.
+
+On Debian jessie kvm i dont have input working at all.
+
+my machine is a G5 quad with Fedora 25 PPC64
+
+thanks
+Luigi
+
+Looking through old bug tickets... is this still an 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/zero-shot/118/peripherals/1673722 b/results/classifier/zero-shot/118/peripherals/1673722
new file mode 100644
index 00000000..1da1d5b1
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1673722
@@ -0,0 +1,143 @@
+peripherals: 0.801
+hypervisor: 0.795
+user-level: 0.748
+permissions: 0.737
+risc-v: 0.694
+KVM: 0.682
+graphic: 0.672
+mistranslation: 0.669
+network: 0.666
+vnc: 0.624
+VMM: 0.623
+architecture: 0.617
+arm: 0.612
+device: 0.604
+performance: 0.602
+assembly: 0.601
+boot: 0.584
+files: 0.578
+register: 0.571
+ppc: 0.568
+kernel: 0.563
+socket: 0.560
+virtual: 0.554
+semantic: 0.550
+x86: 0.540
+PID: 0.533
+TCG: 0.529
+debug: 0.516
+i386: 0.346
+
+Reading register at offset. It is not fully implemented warning make VM impossible to use
+
+Hi,
+
+Since this commit:
+https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347
+
+We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying:
+e1000: Reading register at offset: 0x00002410. It is not fully implemented. 
+
+User got so much of this warning that they can't use the VM. 
+
+Thanks for the help
+
+On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote:
+> Hi,
+> 
+> Since this commit:
+> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347
+> 
+> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying:
+> e1000: Reading register at offset: 0x00002410. It is not fully implemented. 
+> 
+> User got so much of this warning that they can't use the VM.
+
+CCing the author and maintainers.
+
+DBGOUT() is compiled in by default.  Warnings that can be triggered at a
+high rate by the guest should be off by default or use a
+printf_once()-style macro so they are only printed once and not again.
+
+Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing
+guest-triggerable messages by default?
+
+Stefan
+
+
+On 20 March 2017 at 14:20, Stefan Hajnoczi <email address hidden> wrote:
+> On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote:
+>> Hi,
+>>
+>> Since this commit:
+>> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347
+>>
+>> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying:
+>> e1000: Reading register at offset: 0x00002410. It is not fully implemented.
+>>
+>> User got so much of this warning that they can't use the VM.
+>
+> CCing the author and maintainers.
+>
+> DBGOUT() is compiled in by default.  Warnings that can be triggered at a
+> high rate by the guest should be off by default or use a
+> printf_once()-style macro so they are only printed once and not again.
+>
+> Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing
+> guest-triggerable messages by default?
+
+If we want to report "whoops, we don't implement this yet" messages then
+the recommended way to do that is
+ qemu_log_mask(LOG_UNIMP, "....");
+
+(these are not reported by default but only if the user asks for them.)
+
+thanks
+-- PMM
+
+
+
+
+On 2017年03月20日 22:58, Peter Maydell wrote:
+> On 20 March 2017 at 14:20, Stefan Hajnoczi <email address hidden> wrote:
+>> On Fri, Mar 17, 2017 at 09:47:14AM -0000, Julien Duponchelle wrote:
+>>> Hi,
+>>>
+>>> Since this commit:
+>>> https://github.com/qemu/qemu/commit/bc0f0674f037a01f2ce0870ad6270a356a7a8347
+>>>
+>>> We can no longer use the IOSvL2 image from Cisco. The problem is we got a lot of warning message saying:
+>>> e1000: Reading register at offset: 0x00002410. It is not fully implemented.
+>>>
+>>> User got so much of this warning that they can't use the VM.
+>> CCing the author and maintainers.
+>>
+>> DBGOUT() is compiled in by default.  Warnings that can be triggered at a
+>> high rate by the guest should be off by default or use a
+>> printf_once()-style macro so they are only printed once and not again.
+>>
+>> Leonid: do you want to adjust e1000 DBGOUT() usage to avoid printing
+>> guest-triggerable messages by default?
+> If we want to report "whoops, we don't implement this yet" messages then
+> the recommended way to do that is
+>   qemu_log_mask(LOG_UNIMP, "....");
+>
+> (these are not reported by default but only if the user asks for them.)
+>
+> thanks
+> -- PMM
+>
+
+I don't see a reason that enabling E1000E_DEBUG by default. How about 
+just disable it by default?
+
+Thanks
+
+
+I sent a patch to the mailing list:
+http://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg01294.html
+
+I think this has been fixed by:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b4053c64833
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1675458 b/results/classifier/zero-shot/118/peripherals/1675458
new file mode 100644
index 00000000..20f10749
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1675458
@@ -0,0 +1,111 @@
+peripherals: 0.870
+KVM: 0.844
+network: 0.832
+user-level: 0.783
+virtual: 0.781
+register: 0.760
+device: 0.744
+semantic: 0.734
+graphic: 0.720
+assembly: 0.718
+mistranslation: 0.715
+ppc: 0.713
+hypervisor: 0.710
+x86: 0.706
+boot: 0.701
+arm: 0.699
+architecture: 0.687
+socket: 0.668
+PID: 0.660
+performance: 0.659
+debug: 0.652
+kernel: 0.652
+risc-v: 0.649
+permissions: 0.642
+files: 0.634
+VMM: 0.606
+vnc: 0.584
+i386: 0.492
+TCG: 0.483
+
+attach-interface - unexpected action
+
+Hello,
+
+Not sure where to report this, or if it is a bug. However, I feel like the behaviour is not what would/should be expected.
+
+----------------------------------------------------------------------------------------------------------
+
+Environment:
+KVM Version:		root@hostname:~# virsh version
+      			Compiled against library: libvirt 1.2.9
+			Using library: libvirt 1.2.9
+			Using API: QEMU 1.2.9
+			Running hypervisor: QEMU 2.1.2
+uname -a:		Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
+CPU:			Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz
+Host Debian Version:	8.7 (Jessie)
+Guest Debian Version:	8.7 (Jessie)
+
+----------------------------------------------------------------------------------------------------------
+
+Issue:
+When adding an interface to a live VM, the position of interfaces within the VM may change post reboot.
+It appears a new interface takes up the first available “pci slot”. If you have removed an interface in the past, this will be the one that is taken up.
+
+----------------------------------------------------------------------------------------------------------
+
+Example:
+
+If the VM Has the following interfaces layout:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 11:11:11:11:11:11
+eth2  HWaddr 22:22:22:22:22:22
+eth3  HWaddr 33:33:33:33:33:33
+
+Now I delete the interface with MAC address 11:11:11:11:11:11, you now have this:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 22:22:22:22:22:22
+eth2  HWaddr 33:33:33:33:33:33
+
+And then you add a new interface with MAC address 44:44:44:44:44:44, using virsh:
+
+virsh attach-interface --domain guest --type bridge --source br3 --mac 44:44:44:44:44:44 --model e1000 --target vmeth3 --live --persistent
+
+It will now look like this:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 22:22:22:22:22:22
+eth2  HWaddr 33:33:33:33:33:33
+eth3  HWaddr 44:44:44:44:44:44
+
+However, after a reboot, it will look like this:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 44:44:44:44:44:44
+eth2  HWaddr 22:22:22:22:22:22
+eth3  HWaddr 33:33:33:33:33:33 
+
+This can be a problem, as /etc/network/interfaces file, etc., will be pointing to the wrong interfaces. I.E. originally eth1 was connected to br1 (for example), after reboot eth1 is now connected to br3.
+
+To resolve this issue, I need to edit the .xml file in the KVM machine, and edit the following lines:
+
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/>
+
+Changing these into the order I want them to be loaded in, i.e. eth0, eth1, eth2…. (I know 4 are taken already and not usable by ethernet interfaces.)
+
+----------------------------------------------------------------------------------------------------------
+
+
+Thanks in advance.
+
+Kind regards,
+
+Aaron Doyle
+
+Looking through old bug tickets ... Have you tried to discuss this issue with the libvirt people? They might need to have a look at your virsh commands first before one could decide whether this is a libvirt or a qemu problem...
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/168 b/results/classifier/zero-shot/118/peripherals/168
new file mode 100644
index 00000000..fe5b5996
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/168
@@ -0,0 +1,31 @@
+peripherals: 0.976
+device: 0.951
+ppc: 0.945
+mistranslation: 0.937
+graphic: 0.679
+debug: 0.659
+architecture: 0.655
+network: 0.611
+semantic: 0.546
+performance: 0.483
+files: 0.319
+register: 0.282
+boot: 0.271
+arm: 0.249
+VMM: 0.188
+vnc: 0.167
+permissions: 0.165
+virtual: 0.109
+PID: 0.107
+kernel: 0.096
+risc-v: 0.094
+user-level: 0.086
+TCG: 0.076
+hypervisor: 0.066
+assembly: 0.036
+socket: 0.033
+KVM: 0.009
+i386: 0.003
+x86: 0.001
+
+ivshmem PCI device exposes wrong endianness on ppc64le
diff --git a/results/classifier/zero-shot/118/peripherals/1699 b/results/classifier/zero-shot/118/peripherals/1699
new file mode 100644
index 00000000..6287487d
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1699
@@ -0,0 +1,31 @@
+mistranslation: 0.977
+peripherals: 0.931
+semantic: 0.618
+graphic: 0.486
+device: 0.360
+performance: 0.278
+boot: 0.244
+arm: 0.226
+vnc: 0.224
+ppc: 0.196
+debug: 0.195
+VMM: 0.177
+i386: 0.169
+architecture: 0.167
+register: 0.158
+user-level: 0.147
+risc-v: 0.139
+TCG: 0.113
+permissions: 0.107
+KVM: 0.103
+network: 0.071
+files: 0.061
+socket: 0.051
+virtual: 0.042
+assembly: 0.034
+PID: 0.029
+x86: 0.024
+hypervisor: 0.009
+kernel: 0.005
+
+Tricore: Call instruction wrong
diff --git a/results/classifier/zero-shot/118/peripherals/1701449 b/results/classifier/zero-shot/118/peripherals/1701449
new file mode 100644
index 00000000..02e36109
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1701449
@@ -0,0 +1,109 @@
+peripherals: 0.911
+debug: 0.901
+hypervisor: 0.864
+graphic: 0.849
+risc-v: 0.847
+architecture: 0.843
+device: 0.824
+performance: 0.821
+user-level: 0.818
+semantic: 0.788
+PID: 0.772
+mistranslation: 0.772
+virtual: 0.727
+files: 0.720
+KVM: 0.710
+ppc: 0.698
+VMM: 0.666
+assembly: 0.646
+x86: 0.623
+TCG: 0.606
+socket: 0.604
+permissions: 0.604
+boot: 0.593
+register: 0.556
+arm: 0.551
+vnc: 0.484
+network: 0.469
+kernel: 0.452
+i386: 0.438
+
+high memory usage when using rbd with client caching
+
+Hi,
+we are experiencing a quite high memory usage of a single qemu (used with KVM) process when using RBD with client caching as a disk backend. We are testing with 3GB memory qemu virtual machines and 128MB RBD client cache. When running 'fio' in the virtual machine you can see that after some time the machine uses a lot more memory (RSS) on the hypervisor than she should. We have seen values (in real production machines, no artificially fio tests) of 250% memory overhead. I reproduced this with qemu version 2.9 as well.
+
+Here the contents of our ceph.conf on the hypervisor:
+"""
+[client]
+rbd cache writethrough until flush = False
+rbd cache max dirty = 100663296
+rbd cache size = 134217728
+rbd cache target dirty = 50331648
+"""
+
+How to reproduce:
+* create a virtual machine with a RBD backed disk (100GB or so)
+* install a linux distribution on it (we are using Ubuntu)
+* install fio (apt-get install fio)
+* run fio multiple times with (e.g.) the following test file:
+"""
+# This job file tries to mimic the Intel IOMeter File Server Access Pattern
+[global]
+description=Emulation of Intel IOmeter File Server Access Pattern
+randrepeat=0
+filename=/root/test.dat
+# IOMeter defines the server loads as the following:
+# iodepth=1     Linear
+# iodepth=4     Very Light
+# iodepth=8     Light
+# iodepth=64    Moderate
+# iodepth=256   Heavy
+iodepth=8
+size=80g
+direct=0
+ioengine=libaio
+
+[iometer]
+stonewall
+bs=4M
+rw=randrw
+
+[iometer_just_write]
+stonewall
+bs=4M
+rw=write
+
+[iometer_just_read]
+stonewall
+bs=4M
+rw=read
+"""
+
+You can measure the virtual machine RSS usage on the hypervisor with:
+  virsh dommemstat <machine name> | grep rss
+or if you are not using libvirt:
+  grep RSS /proc/<PID of qemu process>/status
+
+When switching off the RBD client cache, all is ok again, as the process does not use so much memory anymore.
+
+There is already a ticket on the ceph bug tracker for this ([1]). However I can reproduce that memory behaviour only when using qemu (maybe it is using librbd in a special way?). Running directly 'fio' with the rbd engine does not result in that high memory usage.
+
+[1] http://tracker.ceph.com/issues/20054
+
+We are seeing pretty much the same issue with even small (1G mem) virtual instances using 2-3GB of RSS after running I/O intensive applications. Live migrating the instance to another machine pushes the memory usage back, but it will grow back again once I/O is back.
+
+Any update on this?
+
+Linking back to bug 1674481 which I think is the same issue seen in Ubuntu
+
+Is there any progress on solving this or does anyone has an idea how to further debug this? I think we are kinda stuck in the ceph bug tracker issue as well [1].
+
+[1] http://tracker.ceph.com/issues/20054
+
+Any reason we are keeping this bug and #1674481 separate? We are not sure?
+
+@Nick: if you can recreate the librbd memory growth, any chance you can help test a potential fix [1]?
+
+[1] https://github.com/ceph/ceph/pull/24297
+
diff --git a/results/classifier/zero-shot/118/peripherals/1711316 b/results/classifier/zero-shot/118/peripherals/1711316
new file mode 100644
index 00000000..8d95bbdd
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1711316
@@ -0,0 +1,114 @@
+peripherals: 0.904
+user-level: 0.902
+register: 0.890
+graphic: 0.876
+VMM: 0.871
+permissions: 0.867
+hypervisor: 0.865
+ppc: 0.861
+debug: 0.854
+KVM: 0.846
+device: 0.841
+mistranslation: 0.841
+architecture: 0.840
+vnc: 0.836
+semantic: 0.830
+assembly: 0.827
+arm: 0.826
+performance: 0.818
+PID: 0.810
+TCG: 0.799
+risc-v: 0.796
+network: 0.787
+kernel: 0.772
+virtual: 0.768
+boot: 0.728
+files: 0.706
+socket: 0.691
+x86: 0.575
+i386: 0.410
+
+fbsd strip(1) segfaults on aarch64
+
+Hello,
+
+During port builds ld.lld(devel/boost-libs, www/node), and strip (textproc/libxml2 on xmlcatalog) are segfaulting. On physical boxes these things do work, as they should:
+
+root@build-aarch64:~ # strip xmlcatalog
+Segmentation fault (core dumped)
+
+All the cores fail at the same assembly instruction, here's strip's backtrace:
+# lldb -c strip.core strip
+(lldb) target create "strip" --core "strip.core"
+Core file '/root/strip.core' (aarch64) was loaded.
+(lldb) t 1
+* thread #1, name = 'strip', stop reason = signal SIGSEGV
+    frame #0: 0x0000000040312f40 libc.so.7`memcpy + 192
+libc.so.7`memcpy:
+->  0x40312f40 <+192>: ldp    x4, x3, [x4, #-0x10]
+    0x40312f44 <+196>: stp    x6, x7, [x0]
+    0x40312f48 <+200>: stp    x8, x9, [x0, #0x10]
+    0x40312f4c <+204>: stp    x10, x11, [x0, #0x20]
+(lldb) bt
+* thread #1, name = 'strip', stop reason = signal SIGSEGV
+  * frame #0: 0x0000000040312f40 libc.so.7`memcpy + 192
+    frame #1: 0x000000004017ac70 libelf.so.2`_libelf_cvt_HALF_tom(dst=<unavailable>, dsz=<unavailable>, src=<unavailable>, count=<unavailable>, byteswap=<unavailable>) at libelf_convert.c:794
+    frame #2: 0x0000000040177b34 libelf.so.2`elf_getdata(s=0x0000000040f355a0, ed=<unavailable>) at elf_data.c:155
+    frame #3: 0x00000000000283d4 strip`copy_data(s=0x0000000040f36a40) at sections.c:1176
+    frame #4: 0x0000000000027ea4 strip`copy_content(ecp=<unavailable>) at sections.c:594
+    frame #5: 0x0000000000023ff4 strip`create_elf(ecp=0x0000000040ed6000) at main.c:381
+    frame #6: 0x000000000002558c strip`create_file(ecp=<unavailable>, src=<unavailable>, dst=<unavailable>) at main.c:705
+    frame #7: 0x0000000000024e20 strip`main [inlined] strip_main(argc=<unavailable>, argv=<unavailable>) at main.c:1192
+    frame #8: 0x0000000000024cc8 strip`main(argc=<unavailable>, argv=<unavailable>) at main.c:1590
+    frame #9: 0x0000000000020190 strip`__start + 376
+    frame #10: 0x0000000040050018 ld-elf.so.1`.rtld_start at rtld_start.S:41
+
+Host system information:
+# uname -a
+FreeBSD marvin.harmless.hu 11.0-STABLE FreeBSD 11.0-STABLE #0 r311927: Wed Jan 11 14:53:55 CET 2017     <email address hidden>:/usr/obj/usr/src/sys/MARVIN  amd64
+
+# qemu-system-aarch64 --version
+QEMU emulator version 2.9.0
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+# pkg info | grep qemu
+qemu-2.9.0                     QEMU CPU Emulator
+I also had this happening with 2.8.0 and 2.8.1
+
+Guest information:
+# uname -a
+FreeBSD build-aarch64.marvin.harmless.hu 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r322578: Wed Aug 16 18:08:43 CEST 2017     <email address hidden>:/tank/rpi3/obj/arm64.aarch64/tank/rpi3/src/sys/GENERIC-NODEBUG  arm64
+
+Startup:
+zdev=/dev/zvol/tank/rpi3/qemu-image
+qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
+                    -accel tcg,thread=single \
+                    -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \
+                    -drive if=none,file=${image},id=hd0,format=raw \
+                    -device virtio-blk-device,drive=hd0 \
+                    -device e1000,netdev=net0 \
+                    -netdev tap,id=net0,ifname=tap0,script=/tank/rpi3/build/qemu-ifup.sh
+
+Tested with cortex A53 as well, does the same.
+
+I've attached a test image to reproduce with (340MB), if it's too big for an attachment, it can be downloaded from here:
+http://czg.harmless.hu/qemu-bug-stripsigsegv/image.gz
+
+Reproduction steps:
+1) log in as root, no password
+2) strip xmlcatalog, it will segfault
+
+For a full reproduction with ld.lld as well, you need a ports tree, it's suggested to attach a bigger volume to /usr/ports over NFS first (it might need more space than the image has). Steps for it:
+1) portsnap fetch extract
+2) make -C /usr/ports/devel/boost-libs package-recursive
+3) make -C /usr/ports/textproc/libxml2 package-recursive
+4) make -C /usr/ports/www/node package-recursive
+
+Boost and node can take a day or more in a qemu VM. The build-time options I've be set already, /var/db/ports is populated, so you shouldn't have questions asked during the builds.
+
+I've saved the core dumps, those can be found at /root/cores/ in the image.
+
+I hope I've submitted all the required information. If anything else is needed, please let me know.
+
+Best regards,
+Gergely
+
diff --git a/results/classifier/zero-shot/118/peripherals/1731277 b/results/classifier/zero-shot/118/peripherals/1731277
new file mode 100644
index 00000000..b2ccf501
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1731277
@@ -0,0 +1,71 @@
+peripherals: 0.937
+i386: 0.927
+x86: 0.927
+user-level: 0.917
+mistranslation: 0.822
+graphic: 0.822
+architecture: 0.813
+arm: 0.777
+device: 0.748
+semantic: 0.696
+files: 0.659
+performance: 0.643
+ppc: 0.633
+register: 0.619
+permissions: 0.590
+socket: 0.568
+PID: 0.561
+vnc: 0.535
+VMM: 0.533
+debug: 0.525
+TCG: 0.475
+network: 0.469
+hypervisor: 0.456
+risc-v: 0.450
+virtual: 0.421
+kernel: 0.419
+assembly: 0.394
+KVM: 0.391
+boot: 0.355
+
+Provide target specific qemu man pages
+
+Right now, all qemu target binaries (qemu-system-...) share the same man page.
+
+The current man page is primarily focused on x86, and therefore the information given is entirely wrong for e.g. arm, powerpc or s390x.
+
+NAME
+       qemu-doc - QEMU Emulator User Documentation
+
+SYNOPSIS
+       qemu-system-i386 [options] [disk_image]
+
+DESCRIPTION
+       The QEMU PC System emulator simulates the following peripherals:
+
+       -   i440FX host PCI bridge and PIIX3 PCI to ISA bridge
+
+       -   Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non
+           standard modes).
+
+       -   PS/2 mouse and keyboard
+
+       -   2 PCI IDE interfaces with hard disk and CD-ROM support
+
+       -   Floppy disk
+
+...
+
+We should have target specific man pages, with the common options/settings factored out, so they are included in all target specific man pages.
+
+"man qemu-system-s390x" should give s390x specific (+common) information and "man qemu-system-x86_64" should contain x86 specific (+common) information.
+
+I'm kind of hoping that moving to Sphinx for our docs toolchain will allow us to for instance have the board specific information in doc comments in each board source file, which could then be automatically assembled into the right documentation. The current manpages are autobuilt from the monolithic qemu-doc.texi, which is woefully out of date in many areas...
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1732679 b/results/classifier/zero-shot/118/peripherals/1732679
new file mode 100644
index 00000000..d5968ac2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1732679
@@ -0,0 +1,126 @@
+peripherals: 0.945
+permissions: 0.945
+graphic: 0.937
+TCG: 0.933
+semantic: 0.916
+vnc: 0.910
+register: 0.910
+assembly: 0.897
+device: 0.879
+arm: 0.867
+ppc: 0.863
+debug: 0.862
+PID: 0.859
+user-level: 0.857
+hypervisor: 0.851
+VMM: 0.850
+mistranslation: 0.847
+virtual: 0.840
+socket: 0.833
+boot: 0.820
+network: 0.817
+risc-v: 0.815
+architecture: 0.803
+performance: 0.795
+files: 0.790
+x86: 0.780
+KVM: 0.774
+kernel: 0.666
+i386: 0.646
+
+Cisco NX-OSv 9k crashes during boot with qemu 2.10.1(Debian 1:2.10.0+dfsg-2) and ovmf 0~20161202.7bbe0b3e-1
+
+Ubuntu 17.04
+qemu 2.10.1(Debian 1:2.10.0+dfsg-2)
+gns3 2.0.3
+NX-OSv 9k 7.0.3.I6.1
+
+- No such issue with previous qemu 2.8.x
+- the issue does not seem to come from the debian packaging
+- the issue does not seem to come from GNS3 either, as confirmed by Jeremy Grossmann at https://github.com/GNS3/gns3-server/issues/1193#issuecomment-344240460
+
+Either some parameters usage have changed (for instance -bios) (which would make qemu not backwards compatible) or there is an issue with qemu itself.
+The configuration parameters are:
+```
+                "compute_id": "local",
+                "console": 2010,
+                "console_type": "telnet",
+                "first_port_name": "mgmt0",
+                "height": 48,
+                "label": {
+                    "rotation": 0,
+                    "style": "font-family: TypeWriter;font-size: 10.0;font-weight: bold;fill: #000000;fill-opacity: 1.0;",
+                    "text": "NX_OSv_9k_Spine_31",
+                    "x": -54,
+                    "y": -25
+                },
+                "name": "NX_OSv_9k_Spine_31",
+                "node_id": "8d01119a-0adc-41bc-950b-c5639db7708c",
+                "node_type": "qemu",
+                "port_name_format": "Ethernet1/{port1}",
+                "port_segment_size": 0,
+                "properties": {
+                    "acpi_shutdown": false,
+                    "adapter_type": "e1000",
+                    "adapters": 10,
+                    "bios_image": "",
+                    "bios_image_md5sum": null,
+                    "boot_priority": "c",
+                    "cdrom_image": "",
+                    "cdrom_image_md5sum": null,
+                    "cpu_throttling": 0,
+                    "cpus": 2,
+                    "hda_disk_image": "NX-OSv-9k-7.0.3.I6.1.free.qcow2",
+                    "hda_disk_image_md5sum": "18bb991b814a508d1190575f99deed99",
+                    "hda_disk_interface": "ide",
+                    "hdb_disk_image": "",
+                    "hdb_disk_image_md5sum": null,
+                    "hdb_disk_interface": "ide",
+                    "hdc_disk_image": "",
+                    "hdc_disk_image_md5sum": null,
+                    "hdc_disk_interface": "ide",
+                    "hdd_disk_image": "",
+                    "hdd_disk_image_md5sum": null,
+                    "hdd_disk_interface": "ide",
+                    "initrd": "",
+                    "initrd_md5sum": null,
+                    "kernel_command_line": "",
+                    "kernel_image": "",
+                    "kernel_image_md5sum": null,
+                    "legacy_networking": false,
+                    "mac_address": "00:07:00:03:16:01",
+                    "options": "-nographic -enable-kvm -cpu host -machine q35 -smp cpus=2 -bios /usr/share/ovmf/OVMF.fd",
+                    "platform": "x86_64",
+                    "process_priority": "normal",
+                    "qemu_path": "/usr/bin/qemu-system-x86_64",
+                    "ram": 6144,
+                    "usage": ""
+```
+
+The logs are:
+- [execution log](https://github.com/GNS3/gns3-server/files/1381651/qemu.log.txt)
+- [terminal log](https://github.com/GNS3/gns3-server/files/1381660/terminal.log.txt)
+
+With the latest qemu, I can boot:
+- Cisco IOSv 15.6(2)T
+- Cisco IOSv-L2 15.2(20170321:233949)
+- Cisco CSR 1000v 16.5.1b
+- Cisco ASAv 9.6(2)
+
+The major difference with NX-OSv 9k is the bios parameter: ```-bios /usr/share/ovmf/OVMF.fd```: 
+```
+ll /usr/share/ovmf/OVMF.fd
+-rw-r--r-- 1 root root 2097152 Dec  9  2016 /usr/share/ovmf/OVMF.fd
+```
+A normal boot log with qemu 2.8.1 is available [here](https://github.com/GNS3/gns3-server/files/1381729/terminal.log.2.8.txt)
+
+Highlighting the differences: qemu 2.8.1 on the left, qemu 2.10.1 on the right hand side with the same boot parameters
+![qemu 2 8 vs qemu 2 10](https://user-images.githubusercontent.com/13176858/31534998-8429462e-aff9-11e7-9cf3-bf2b00c21e8a.jpg)
+
+Actually, this issue is solved with a fresher ovmf package than the one shipped by default with Ubuntu 17.04 (0~20161202.7bbe0b3e-1).
+
+This issue should be closed.
+
+
+Closing, according to the previous comment.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1762707 b/results/classifier/zero-shot/118/peripherals/1762707
new file mode 100644
index 00000000..80ac0e14
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1762707
@@ -0,0 +1,68 @@
+peripherals: 0.897
+permissions: 0.887
+graphic: 0.853
+architecture: 0.852
+device: 0.846
+debug: 0.770
+socket: 0.753
+semantic: 0.752
+mistranslation: 0.751
+assembly: 0.750
+files: 0.744
+performance: 0.742
+network: 0.740
+virtual: 0.709
+PID: 0.705
+kernel: 0.702
+hypervisor: 0.694
+register: 0.694
+VMM: 0.682
+arm: 0.675
+user-level: 0.633
+KVM: 0.608
+ppc: 0.598
+vnc: 0.594
+i386: 0.586
+risc-v: 0.559
+boot: 0.524
+x86: 0.484
+TCG: 0.372
+
+VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem
+
+Is there any known conflict between VFIO passthrough device and virtio-balloon?
+
+The VM has:
+1. 4GB system memory
+2. one VFIO passthrough device which supports high address memory DMA and uses GFP_HIGHUSER pages.
+3. Memory balloon device with 4GB target.
+
+When setting the memory balloon target to 1GB and 4GB in loop during runtime (I used the command "virsh qemu-monitor-command debian --hmp --cmd balloon 1024"), the VFIO device DMA randomly gets failure.
+
+More clues:
+1. configure 2GB system memory (no highmem) VM, no issue with similar operations
+2. setting the memory balloon to higher like 8GB, no issue with similar operations
+
+I'm also trying to narrow down this issue. It's appreciated for that you guys may share some thoughts.
+
+Ballooning is currently incompatible with device assignment.  When the balloon is inflated (memory removed from the VM), the pages are zapped from the process without actually removing them from the vfio DMA mapping.  The pages are still pinned from the previous mapping, making the balloon inflation ineffective (pages are not available for re-use).  When the balloon is deflated, new (different) pages are faulted in for the previously zapped pages, but these are again not DMA mapped for the IOMMU, so now the physical memory backing a given address in the VM are different for processor and assigned device access and DMA will fail.  In order to support this, QEMU would need to do more than simply zap pages from the process address space, they'd need to be unmapped from the IOMMU, but we can only do that using the original mapping size.  Effectively, memory hotplug is a better solution when device assignment is involved.
+
+Hi Alex, Thanks for your confirming. change the status to invalid.
+
+I think we can raise this issue to libvirt. When using virsh or virt-manager, the memory balloon is still enabled by default even if there's a device assignment. 
+
+Alex, I see this issue is closed but I have a question, do you know if the problem only comes the balloon is resized to return memory to the host. I ask because we have a situation where we will start a VM with balloon enabled, and later it maybe possible a devices is assigned via hot-plug. So I would like to avoid this issue by doing the following:
+
+if a vfio devices is assigned;
+   resize the balloon size the the maximal guest memory
+end 
+
+Then because we know we added a vfio devices never resize the balloon to return memory again.
+
+More information about what we want to do: https://github.com/kata-containers/runtime/pull/793
+
+Regards,
+Carlos
+
+There are two scenarios here, if we have a regular, directly assigned physical device (including VFs), vfio's page pinning will populate the full memory footprint of the guest regardless of the balloon.  The balloon is effectively fully deflated, but the balloon driver in the guest hasn't released the pages back for guest kernel use.  In that case marking the balloon as deflated at least allows those pages to be used since they're allocated.  However, if the assigned device is an mdev device, then the pages might only be pinned on usage, depending on the vendor driver, and pages acquired by the guest balloon driver are unlikely to be used by the in-guest driver for the device.  It's always possible that the mdev vendor driver could pin them anyway, but there is a chance that those pages are actually still freed to the host until that point.  Latest QEMU will of course enable the  balloon inhibitor for either case so further balloon inflation will no longer zap pages.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1770417 b/results/classifier/zero-shot/118/peripherals/1770417
new file mode 100644
index 00000000..3d9ec1d3
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1770417
@@ -0,0 +1,84 @@
+peripherals: 0.950
+graphic: 0.928
+register: 0.919
+device: 0.912
+virtual: 0.895
+permissions: 0.887
+socket: 0.881
+x86: 0.880
+boot: 0.872
+hypervisor: 0.858
+network: 0.854
+performance: 0.852
+mistranslation: 0.848
+architecture: 0.847
+kernel: 0.846
+semantic: 0.845
+debug: 0.843
+user-level: 0.842
+PID: 0.819
+assembly: 0.816
+arm: 0.800
+risc-v: 0.779
+vnc: 0.769
+files: 0.753
+VMM: 0.710
+ppc: 0.671
+TCG: 0.653
+KVM: 0.628
+i386: 0.474
+
+Qemu can not parse long fqdns during drive-mirror
+
+During migration of an openstack booted instance, I got the following error:
+
+Apr 12 10:55:22 cmp1 libvirtd[4133]: 2018-04-12 10:55:22.133+0000: 4139: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'drive-mirror': error parsing address 'cmp0.sandriichenko-deploy-heat-virtual-mcp-pike-ovs-76.bud-mk.local:49153'
+
+A bit more info in libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1568939
+
+To reproduce it with qemu only, I followed the guide at https://github.com/qemu/qemu/blob/master/docs/interop/live-block-operations.rst#id21. On dest and source compute nodes, I launched an instance:
+
+qemu-system-x86_64 -display none -nodefconfig -M q35 -nodefaults -m 512 -blockdev node-name=node-TargetDisk,driver=qcow2,file.driver=file,file.node-name=file,file.filename=./test-instance-mirror.qcow2 -device virtio-blk,drive=node-TargetDisk,id=virtio0 -S -monitor stdio -qmp unix:./qmp-sock,server,nowait -incoming tcp:localhost:6666
+
+Then on dest node I launched nbd server:
+
+(qemu) nbd_server_start cmp0:49153
+(qemu) nbd_server_add -w node-TargetDisk
+
+On the source node:
+
+(qemu) drive_mirror -n  node-TargetDisk nbd:cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153:exportname=node-TargetDisk
+error parsing address 'cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153'
+
+When using short host name instead of FQDN address seems to be parsed fine:
+
+(qemu) drive_mirror -n  node-TargetDisk nbd:cmp0:49153:exportname=node-TargetDisk qcow2
+Image is not in qcow2 format
+
+(not sure why it is not a qcow2 format, as I have qcow2 image with raw backing file, but this is unrelated)
+
+QEMU version is 2.11.1 from bionic
+
+As Daniel asked in [1] making this abug report against Qemu (upstream).
+
+[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1568939 
+
+Ubuntu task is not actionable until we settled on how to change the parsing code for long strings upstream, so I set it to confirmed but wishlist (until we know what size a patch - or actions a recommendation on handling differently has).
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1771042 b/results/classifier/zero-shot/118/peripherals/1771042
new file mode 100644
index 00000000..b4239a25
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1771042
@@ -0,0 +1,98 @@
+peripherals: 0.850
+vnc: 0.841
+semantic: 0.822
+assembly: 0.816
+user-level: 0.804
+mistranslation: 0.804
+arm: 0.748
+device: 0.743
+PID: 0.734
+ppc: 0.732
+debug: 0.729
+TCG: 0.722
+permissions: 0.702
+graphic: 0.701
+KVM: 0.695
+performance: 0.687
+VMM: 0.682
+hypervisor: 0.674
+risc-v: 0.672
+register: 0.661
+x86: 0.628
+virtual: 0.625
+architecture: 0.609
+network: 0.597
+boot: 0.593
+files: 0.576
+socket: 0.547
+kernel: 0.473
+i386: 0.426
+
+dataplane interrupt handler doesn't support msi
+
+hw/block/dataplane/virtio-blk.c commit 1010cadf62332017648abee0d7a3dc7f2eef9632
+
+in the function notify_guest_bh, the function virtio_notify_irqfd is called
+to deliver the interrupt corresponding to the vq
+
+however, without the dataplane, hw/block/virtio_blk_req_complete calls
+virtio_notify to deliver the interrupt (immediately). this goes though
+a slightly more involved path that calls virtio_pci_notify which includes
+a case to handle msi interrupts.
+
+so, msi interrupts with block devices aren't serviced when using dataplane
+batching.
+
+diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
+index 101f32c..31d9eb8 100644
+--- a/hw/block/dataplane/virtio-blk.c
++++ b/hw/block/dataplane/virtio-blk.c
+@@ -73,7 +73,7 @@ static void notify_guest_bh(void *opaque)
+             unsigned i = j + ctzl(bits);
+             VirtQueue *vq = virtio_get_queue(s->vdev, i);
+
+-            virtio_notify_irqfd(s->vdev, vq);
++            virtio_notify(s->vdev, vq);
+
+             bits &= bits - 1; /* clear right-most bit */
+         }
+
+
+oh right, another note. this only manifests when using kvm.
+
+
+On Mon, May 14, 2018 at 03:00:44AM -0000, eric hoffman wrote:
+> diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
+> index 101f32c..31d9eb8 100644
+> --- a/hw/block/dataplane/virtio-blk.c
+> +++ b/hw/block/dataplane/virtio-blk.c
+> @@ -73,7 +73,7 @@ static void notify_guest_bh(void *opaque)
+>              unsigned i = j + ctzl(bits);
+>              VirtQueue *vq = virtio_get_queue(s->vdev, i);
+> 
+> -            virtio_notify_irqfd(s->vdev, vq);
+> +            virtio_notify(s->vdev, vq);
+> 
+>              bits &= bits - 1; /* clear right-most bit */
+>          }
+
+Please send patches to <email address hidden>.  Guidelines for submitting
+patches are here:
+https://wiki.qemu.org/Contribute/SubmitAPatch
+
+The issue with this approach is that hw/pci/msi.c:msi_send_message()
+invokes device emulation outside the QEMU global mutex (it calls into
+the APIC to send MSIs).  I've CCed Paolo Bonzini to check whether doing
+this is thread-safe.
+
+Stefan
+
+
+thanks for looking at this Stefan - since I don't have any context of exactly the kind of environmental issues like threading, the patch posted here isn't really a suggested fix.
+
+it does in general seem helpful if batched interrupts have the same delivery semantics as non-deferred. 
+
+This bug is invalid. MSI/MSI-X interrupts are properly serviced when dataplane batching is used. The original problem was in the incorrect virtio driver initialization sequence (virtqueues and MSI-X interrupts configured after DRIVER_OK bit is set).
+
+This bug can be closed as INVALID.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1778966 b/results/classifier/zero-shot/118/peripherals/1778966
new file mode 100644
index 00000000..1df2b622
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1778966
@@ -0,0 +1,66 @@
+peripherals: 0.980
+KVM: 0.971
+boot: 0.938
+hypervisor: 0.901
+architecture: 0.894
+graphic: 0.878
+device: 0.847
+files: 0.828
+ppc: 0.790
+virtual: 0.787
+performance: 0.779
+user-level: 0.760
+semantic: 0.676
+register: 0.637
+mistranslation: 0.636
+PID: 0.624
+permissions: 0.599
+network: 0.578
+x86: 0.474
+debug: 0.457
+kernel: 0.450
+risc-v: 0.439
+assembly: 0.410
+socket: 0.389
+vnc: 0.348
+TCG: 0.332
+VMM: 0.294
+arm: 0.276
+i386: 0.241
+
+Windows 1803 and later crashes on KVM
+
+For a bionic host, using the current public kvm modules, KVM is not capable of booting a WindowsInsider or msdn Windows 1803 iso. In stallign from an ISO from a started windows 2016 guest results in an unbootable and unrepairable guest.
+
+The hardware is a threadripper 1920x with 32GB of main memory, disk mydigital BPX SSD and WD based 4 column RAID 5 via mdadm.
+
+This sounds like the same problem we're investigating in Fedora/RHEL land affecting guests with EPYC CPU, or host-passthrough from an EPYC family 17h host.  Workaround should be to use "-cpu Opteron_G5" for now
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1592276
+https://bugzilla.redhat.com/show_bug.cgi?id=1593190
+
+Looks like windows is tickling an undocumented MSR and we're trying to find out what this MSR is supposed todo and thus how to handle it in KVM/QEMU
+
+That is very helpful. I'll try it. 
+
+I standby to try a fix as soon as someone has one.
+
+Regrettably opteron_g5 is not a workaround. I get a complaint that my cpu doesn't provide xop, fma4, tbm.
+
+I've tried a number of other cpus including nehalem, phenom and athlon with similar results.
+
+Opteron didn't work do to some missing features. I was able to get nehalem to come up but that looks like the closest.
+
+Is there any way to define a new CPU model that isn't EPYC (maybe ryzen?) but is feature compatible with the threadripper?
+
+I ran into the same problem on threadripper 1900X. I was using cpu type "host-passthough" and it crashed. I fixed the crash by disabling the MSR with
+
+kvm.ignore_msrs=1
+
+as describe in https://forum.level1techs.com/t/windows-10-1803-as-guest-with-qemu-kvm-bsod-under-install/127425/10
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1787505 b/results/classifier/zero-shot/118/peripherals/1787505
new file mode 100644
index 00000000..63bcca50
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1787505
@@ -0,0 +1,125 @@
+peripherals: 0.826
+user-level: 0.819
+graphic: 0.794
+hypervisor: 0.793
+vnc: 0.784
+network: 0.784
+risc-v: 0.781
+architecture: 0.781
+ppc: 0.778
+register: 0.778
+permissions: 0.770
+x86: 0.758
+virtual: 0.748
+TCG: 0.736
+KVM: 0.731
+semantic: 0.727
+device: 0.719
+performance: 0.718
+VMM: 0.718
+assembly: 0.707
+socket: 0.690
+files: 0.678
+PID: 0.671
+kernel: 0.656
+debug: 0.651
+arm: 0.643
+boot: 0.636
+i386: 0.515
+mistranslation: 0.495
+
+Solaris host: no network connection, mouse pointer mismatch
+
+This is probably a bit far afield but on a Solaris 10 SPARC host (Sun M3000) running a Windows XP guest like this:
+
+./qemu-system-x86_64 -m 1024 -boot d  -smp 3 -net nic -net user -hda  /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
+
+the vnc server starts up and Windows boots normally.  However, there is no network connectivity.  There are no network devices visible in XP's Networking tab of Control Panel and a ping of the local router reports "unreachable".
+
+Also, the keyboard works fine but the guest mouse pointer is offset from the host mouse position by an amount that varies by screen position.  This makes it impossible to point to locations near the edge of the qemu window.  This seems to be a previously reported problem, but the suggested fix, " -device usb-tablet", prevents qemu from even starting:
+
+qemu-system-x86_64: -device usb-tablet: No 'usb-bus' bus found for device 'usb-tablet'
+
+The physical mouse is connected to the USB port of a Sun Ray 2fs controlling the M3000 via Sun Ray server.  I apologize if this is a configuration issue and not a bug but I don't know where else to report it and have been unable to find a solution in the documentation.
+
+You should maybe try a different NIC model. According to https://wiki.qemu.org/Documentation/Networking the rtl8139 seems to be a good choice?
+
+Concerning USB, you've also got to enable an emulated "USB host controller" to use USB devices. The easiest way to do that is to simply start QEMU with the "-usb" parameter.
+
+If you have access to a Linux box, I'd definitely recommend testing the same setup there. That way you can distinguish "this doesn't work on Solaris" from "this doesn't work generally" -- the latter are (a) more likely to be config/command line issues and (b) are easier for us to work on where there are bugs.
+
+
+Thank you very much.  The following invocation fixed the mouse problem (mostly) and made the Ethernet device available to the guest:
+
+./qemu-system-x86_64 -m 2047 -boot d  -usb -device usb-tablet -smp 3 -netdev user,id=n0 -device rtl8139,netdev=n0 -hda /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso 
+
+There is one minor problem with the mouse.  Without the "-usb" qemu displays the guest cursor position with an arrow, and the host cursor position with a four pixel-wide box, separated by a distance that varies with position on the screen.  After adding "-usb", the guest cursor correctly tracks the host mouse, but the little box remains displayed, speared on the tip on the guest cursor arrow.
+
+Also, while the guest now has a network device it still can't talk to any destination.  Oddly, if I try to ftp to some server it says "connected" but then nothing else.  Web pages all come back as "unreachable" even when requested by IP rather than name.  Even pinging the router fails (though the documentation states that ping won't work anyway).  The guest shows packets beign sent, but none received.  I tried various other options listed in the documentation without success, eg.
+
+# qemu-system-x86_64: Host doesn't belong to network
+ ./qemu-system-x86_64 -m 2047 -boot d  -usb -device usb-tablet  -smp 3 -netdev user,id=n0,host=192.168.0.20, \
+> hostname=canadiceq,dns=127.0.0.1,net=192.168.0.20/24 -device rtl8139,netdev=n0 -hda  /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
+1212
+# qemu-system-x86_64: Host doesn't belong to network
+
+My best guess also didn't work:
+
+./qemu-system-x86_64 -m 2047 -boot d  -usb -device usb-tablet  -smp 3 -netdev user,id=n0,hostfwd=tcp::8080-:80,\
+> net=192.168.0.0/24 -device rtl8139,netdev=n0 -hda  /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
+
+That at least starts up, but no communication.
+
+I guess I just don't understand what needs to be listed where in the qemu invocation.  My guest TCP parameters are set up the same way as a different working XP system.  I can't tell what I need to get the guest to talk to the Internet.  I have a host IP (192.168.0.20), guest IP (192.168.0.21), router IP (192.168.0.1), and DNS IP (208.67.222.222).  What goes where?  Do I need to set up anything special on the Solaris end?  I've read over the documenation but still can't figure it out.
+
+"If you have access to a Linux box, I'd definitely recommend testing the same setup there."
+
+I do, but I only have one legit XP license.
+
+Anyone?  I'm still trying to get my networking working.  On this page: https://en.wikibooks.org/wiki/QEMU/Networking#User_mode_networking, it says
+
+"The guest OS will see an E1000 NIC with a virtual DHCP server on 10.0.2.2 and will be allocated an address starting from 10.0.2.15. A virtual DNS server will be accessible on 10.0.2.3, and a virtual SAMBA file server (if present) will be accessible on 10.0.2.4 allowing you to access files on the host via SAMBA file shares."
+
+That's fine, but my LAN is on 192.186.0.x not, 10.2.0.x.  The following starts qemu but 
+
+./qemu-system-x86_64 -m 2047 -boot d  -usb -device usb-tablet  -smp 3 -netdev user,id=n0,net=192.168.0.0/24 -device rtl8139,netdev=n0 -hda  /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
+
+shows an Ethernet device in XP but is unable to connect to anything via IE.
+
+
+But it also says
+
+"To use this network setup with the Linux kernel, you must set the configuration option CONFIG_E1000=y when compiling."
+
+Does this (to the extent that Linux applies to Solaris) also apply if I'm using an rtl8139 card?
+
+On 31 August 2018 at 01:47, Michele Denber <email address hidden> wrote:
+> Anyone?  I'm still trying to get my networking working.  On this page:
+> https://en.wikibooks.org/wiki/QEMU/Networking#User_mode_networking, it
+> says
+>
+> "The guest OS will see an E1000 NIC with a virtual DHCP server on
+> 10.0.2.2 and will be allocated an address starting from 10.0.2.15. A
+> virtual DNS server will be accessible on 10.0.2.3, and a virtual SAMBA
+> file server (if present) will be accessible on 10.0.2.4 allowing you to
+> access files on the host via SAMBA file shares."
+>
+> That's fine, but my LAN is on 192.186.0.x not, 10.2.0.x.  The following
+> starts qemu but
+
+10.0.2.x, and this is the "virtual" bit of network inside QEMU,
+whose numbering is unrelated to your own network.
+
+User questions probably are better on the mailing list, not
+inside bug reports.
+
+thanks
+-- PMM
+
+
+Sorry about that.  I didn't know where to ask about this.  Anyway thank you for the explanation.  That was the clue I needed.  Instead of giving XP a gateway of 192.168.0.1 in the Networking TCP tab I just set gateway and DNS to automatic.  Networking is all working fine now.  This was the call:
+
+./qemu-system-x86_64  -m 2047  -usb -device usb-tablet -smp 3 -device rtl8139,netdev=net0 -netdev user,id=net0 -boot d -hda  /bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
+
+So this is not a bug, but a configuration issue.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1801 b/results/classifier/zero-shot/118/peripherals/1801
new file mode 100644
index 00000000..994ca8d0
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1801
@@ -0,0 +1,81 @@
+peripherals: 0.870
+mistranslation: 0.717
+hypervisor: 0.680
+TCG: 0.649
+performance: 0.636
+graphic: 0.628
+semantic: 0.613
+assembly: 0.611
+permissions: 0.605
+debug: 0.587
+device: 0.586
+ppc: 0.576
+register: 0.573
+architecture: 0.569
+user-level: 0.558
+socket: 0.539
+PID: 0.537
+arm: 0.528
+vnc: 0.525
+virtual: 0.507
+x86: 0.493
+kernel: 0.490
+VMM: 0.466
+boot: 0.451
+network: 0.447
+risc-v: 0.432
+files: 0.430
+KVM: 0.429
+i386: 0.352
+
+qemu-system-arm: Linux doesn't boot with UEFI (hangs after printing `EFI stub: Exiting boot services... `.)
+Description of problem:
+Ubuntu 23.04 (armhf) doesn't boot with UEFI.
+It hangs after printing `EFI stub: Exiting boot services... `.
+Steps to reproduce:
+```console
+$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot
+UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023)                                                                  
+Error: Image at 000BFD84000 start failed: Not Found                                                                                                  
+Error: Image at 000BFCEE000 start failed: Unsupported                                                                                                
+Error: Image at 000BFC85000 start failed: Not Found                                                                                                  
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+Tpm2GetCapabilityPcrs fail!                                                                                                                          
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)                                                                           
+BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)                                                                          
+EFI stub: Booting Linux Kernel...                                         
+EFI stub: Entering in SVC mode with MMU enabled                  
+EFI stub: Using DTB from configuration table                      
+EFI stub: Exiting boot services... 
+```
+Additional information:
+It still boots when vmlinuz and initrd are directly specified:
+```console
+$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot -kernel ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae -initrd ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae -append "root=LABEL=cloudimg-rootfs ro"                                          
+UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023)                                                                  
+Error: Image at 000BFD84000 start failed: Not Found                                                                                                  
+Error: Image at 000BFCEE000 start failed: Unsupported                                                                                                
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+Tpm2GetCapabilityPcrs fail!                                               
+Tpm2SubmitCommand - Tcg2 - Not Found                                      
+EFI stub: Booting Linux Kernel...                                                                                                                    
+EFI stub: Entering in SVC mode with MMU enabled                                                                                                      
+EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path                                                                                 
+EFI stub: Using DTB from configuration table                                                                                                         
+EFI stub: Exiting boot services...                                                                                                                   
+[    0.000000] Booting Linux on physical CPU 0x0                                                                                                     
+[    0.000000] Linux version 6.2.0-26-generic-lpae (buildd@bos02-arm64-018) (arm-linux-gnueabihf-gcc-12 (Ubuntu 12.2.0-17ubuntu1) 12.2.0, GNU ld (GNU
+ Binutils for Ubuntu) 2.40) #26-Ubuntu SMP Tue Jul 11 10:32:58 UTC 2023 (Ubuntu 6.2.0-26.26-generic-lpae 6.2.13)
+[    0.000000] CPU: ARMv7 Processor [414fc0f0] revision 0 (ARMv7), cr=30c5387d
+...
+Ubuntu 23.04 ubuntu ttyAMA0
+
+ubuntu login:
+```
+
+
+Files:
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/ubuntu-23.04-server-cloudimg-armhf.img
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae
diff --git a/results/classifier/zero-shot/118/peripherals/1801674 b/results/classifier/zero-shot/118/peripherals/1801674
new file mode 100644
index 00000000..b096ddc2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1801674
@@ -0,0 +1,112 @@
+peripherals: 0.892
+permissions: 0.869
+architecture: 0.864
+kernel: 0.846
+ppc: 0.845
+KVM: 0.841
+debug: 0.835
+hypervisor: 0.823
+risc-v: 0.819
+PID: 0.813
+register: 0.810
+semantic: 0.802
+user-level: 0.794
+network: 0.792
+files: 0.791
+virtual: 0.790
+device: 0.790
+performance: 0.783
+arm: 0.775
+TCG: 0.775
+vnc: 0.766
+socket: 0.758
+assembly: 0.757
+graphic: 0.754
+boot: 0.751
+VMM: 0.736
+x86: 0.720
+i386: 0.714
+mistranslation: 0.686
+
+Ubuntu16.04 LTS - PCI Pass Through in Ubuntu KVM 16.04.x must use QEMU with DDW support from PPA (Documentation)
+
+== Comment: #0 - Siraj M. Ismail <email address hidden> - 2016-10-05 11:35:38 ==
+---Problem Description---
+
+Customer running PCI pass through with 16.04.1 KVM and with the stock QEMU packages will hit a DI if they do not update to the QEMU packages with DDW support. The packages are in PPA for customers to download, and test has verified the fix. The details are in Bugzilla 144123. 
+ 
+---uname output---
+Ubuntu 16.04.1 with 4.4.0 Kernel
+ 
+Machine Type = 8247-22L 
+ 
+---Debugger---
+A debugger is not configured
+ 
+---Steps to Reproduce---
+ Run guest with adapters assigned via PCI PT, The guest will start having DI issues as soon as I/O started on the Pass Through adapter. 
+ 
+Contact Information = <email address hidden> 
+ 
+---Patches Installed---
+QEMU was updated from 2.5 version to 2.6.1 with patches for DDW support, can be found at PPA location : 
+https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw
+ 
+Userspace tool common name: QEMU 
+ 
+Documentation version: N/A 
+ 
+The userspace tool has the following bit modes: N/A 
+
+Userspace rpm: N/A 
+
+Userspace tool obtained from project website:  na 
+ 
+*Additional Instructions for <email address hidden>: 
+-Post a private note with access information to the machine that the bug is occuring on.
+-Attach ltrace and strace of userspace application.
+
+== Comment: #5 - Leonardo Augusto Guimaraes Garcia <email address hidden> - 2017-04-25 16:23:57 ==
+I would rephrase to:
+
+-------------------------------
+
+Under KVM recommendations
+
+PCI passthrough recommendations
+
+If you are running PCI passthrough with 16.04.x KVM and with the stock QEMU package, update to the QEMU package that have DDW support. If you do not update the package, you will hit data integrity issues as soon as I/O is started on the adapter.
+
+The package is available at: https://launchpad.net/~ibmpackages/+archive/ubuntu/ddw
+
+-------------------------------
+
+Some time ago DDW was discussed in this ticket:
+https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1541902
+And it got introduced in Yakkety and higher only.
+Due to pretty complex changes and changes in the virtual machine attributes there is no plan to get it into xenial.
+Also 'bugproxy' changed "targetmilestone-inin16041" to "targetmilestone-inin1610".
+We are wondering why this now came up again?
+
+------- Comment From <email address hidden> 2018-11-05 05:57 EDT-------
+(In reply to comment #14)
+> Some time ago DDW was discussed in this ticket:
+> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1541902
+> And it got introduced in Yakkety and higher only.
+> Due to pretty complex changes and changes in the virtual machine attributes
+> there is no plan to get it into xenial.
+> Also 'bugproxy' changed "targetmilestone-inin16041" to
+> "targetmilestone-inin1610".
+> We are wondering why this now came up again?
+
+This bug was lying in LTC bugzilla since a while and i happen to
+mirror it today after the previous QA left IBM.  Its a documentation
+bug for 16.04.x
+
+Okay, added it to:
+- uKVM
+  https://wiki.ubuntu.com/ppc64el/uKVM#PCI_pass-through_with_QEMU-KVM_on_Ubuntu_16.04_using_kernel_4.4
+- and to the Release Notes:
+  https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#PCI_pass-through_with_QEMU-KVM
+Closing ticket.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1802684 b/results/classifier/zero-shot/118/peripherals/1802684
new file mode 100644
index 00000000..4080c8bf
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1802684
@@ -0,0 +1,201 @@
+peripherals: 0.862
+TCG: 0.839
+graphic: 0.821
+register: 0.818
+hypervisor: 0.812
+VMM: 0.806
+permissions: 0.777
+ppc: 0.773
+mistranslation: 0.762
+KVM: 0.757
+semantic: 0.744
+debug: 0.731
+vnc: 0.729
+device: 0.722
+arm: 0.720
+user-level: 0.713
+x86: 0.689
+assembly: 0.687
+PID: 0.665
+performance: 0.639
+risc-v: 0.638
+socket: 0.610
+virtual: 0.602
+architecture: 0.590
+boot: 0.570
+kernel: 0.523
+i386: 0.441
+network: 0.430
+files: 0.331
+
+QEMU gui crashes on macOS Mojave
+
+QEMU release 3.0.0 as well as a recent head build
+
+/usr/local/Cellar/qemu/HEAD-03c1ca1 (147 files, 257.2MB)
+  Built from source on 2018-11-06 at 13:41:32 with: --with-gtk+3 --with-sdl2 --with-libusb
+/usr/local/Cellar/qemu/3.0.0 (137 files, 261.6MB) *
+  Poured from bottle on 2018-11-10 at 22:58:32 with: --with-gtk+3 --with-libusb --with-sdl2
+
+Crashes when attempting to use any gui interface (tried SDL and default Cocoa):
+
+2018-11-10 22:58:41.799 qemu-system-aarch64[42982:1102466] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
+*** First throw call stack:
+(
+	0   CoreFoundation                      0x00007fff3ea96ecd __exceptionPreprocess + 256
+	1   libobjc.A.dylib                     0x00007fff6ab49720 objc_exception_throw + 48
+	2   CoreFoundation                      0x00007fff3eab095d -[NSException raise] + 9
+	3   AppKit                              0x00007fff3bfb13fa -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 324
+	4   AppKit                              0x00007fff3bfb6850 -[NSView setFrameSize:] + 2082
+	5   AppKit                              0x00007fff3c02747d -[NSVisualEffectView setFrameSize:] + 171
+	6   AppKit                              0x00007fff3c0811b1 -[NSTitlebarView setFrameSize:] + 84
+	7   AppKit                              0x00007fff3bfb5859 -[NSView setFrame:] + 478
+	8   AppKit                              0x00007fff3c081154 -[NSTitlebarView resizeWithOldSuperviewSize:] + 100
+	9   AppKit                              0x00007fff3bfbc95e -[NSView resizeSubviewsWithOldSize:] + 502
+	10  AppKit                              0x00007fff3bfb66d9 -[NSView setFrameSize:] + 1707
+	11  AppKit                              0x00007fff3c9773c0 -[NSTitlebarContainerView setFrameSize:] + 142
+	12  AppKit                              0x00007fff3bfb5859 -[NSView setFrame:] + 478
+	13  AppKit                              0x00007fff3bfbcdb5 -[NSView resizeWithOldSuperviewSize:] + 776
+	14  AppKit                              0x00007fff3bfbc95e -[NSView resizeSubviewsWithOldSize:] + 502
+	15  AppKit                              0x00007fff3bfb66d9 -[NSView setFrameSize:] + 1707
+	16  AppKit                              0x00007fff3c024570 -[NSThemeFrame setFrameSize:] + 495
+	17  AppKit                              0x00007fff3c011223 -[NSWindow _setFrame:updateBorderViewSize:] + 966
+	18  AppKit                              0x00007fff3c010b46 -[NSWindow _oldPlaceWindow:] + 547
+	19  AppKit                              0x00007fff3c010151 -[NSWindow _setFrameCommon:display:stashSize:] + 3006
+	20  AppKit                              0x00007fff3c00f57d -[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 192
+	21  AppKit                              0x00007fff3c019ff8 -[NSWindow setFrame:display:animate:] + 567
+	22  qemu-system-aarch64                 0x000000010b7b2abf qemu-system-aarch64 + 3668671
+	23  qemu-system-aarch64                 0x000000010b7b6356 qemu-system-aarch64 + 3683158
+	24  qemu-system-aarch64                 0x000000010b7ad836 qemu-system-aarch64 + 3647542
+	25  qemu-system-aarch64                 0x000000010b4ce769 qemu-system-aarch64 + 636777
+	26  qemu-system-aarch64                 0x000000010b487c24 qemu-system-aarch64 + 347172
+	27  qemu-system-aarch64                 0x000000010b487a15 qemu-system-aarch64 + 346645
+	28  qemu-system-aarch64                 0x000000010b4878f1 qemu-system-aarch64 + 346353
+	29  qemu-system-aarch64                 0x000000010b4414aa qemu-system-aarch64 + 58538
+	30  qemu-system-aarch64                 0x000000010b4f78c3 qemu-system-aarch64 + 805059
+	31  qemu-system-aarch64                 0x000000010b487c24 qemu-system-aarch64 + 347172
+	32  qemu-system-aarch64                 0x000000010b487a15 qemu-system-aarch64 + 346645
+	33  qemu-system-aarch64                 0x000000010b4878f1 qemu-system-aarch64 + 346353
+	34  qemu-system-aarch64                 0x000000010b4b8f57 qemu-system-aarch64 + 548695
+	35  qemu-system-aarch64                 0x000000010b49c3af qemu-system-aarch64 + 431023
+	36  ???                                 0x00000001117891f3 0x0 + 4588081651
+)
+libc++abi.dylib: terminating with uncaught exception of type NSException
+fish: 'qemu-system-aarch64 -M raspi3 -…' terminated by signal SIGABRT (Abort)
+
+
+macOS Mojave 10.14.2 Beta (18C38b)
+Qemu in the same configuration used to work in High Sierra, started crashing only after upgrade to Mojave.
+
+Command line:
+`qemu-system-aarch64 -M raspi3 -d in_asm -serial stdio -kernel $1.bin`
+
+Thanks for the bug report. It looks like Mojave is pickier about apps not calling various GUI update functions from the "wrong" thread. We probably need to figure out how to dispatch those to the main thread instead of whatever thread we were on. Unfortunately we don't really have anybody in QEMU upstream who knows much about OSX or its GUI, and I suspect we don't have anybody with Mojave (my system is still High Sierra and I don't plan to upgrade it for a while); help and patches appreciated from anybody who does...
+
+
+I'll see if I have some time this weekend to dig into qemu Cocoa layer.
+
+The code for the cocoa stuff is in ui/cocoa.m. Quick notes on structure:
+
+ * there is a weird thing where cocoa.m provides its own main(), and arranges that the function which is main() for every other UI is renamed qemu_main() and called later (I'd like to get rid of that one day if we could, it's just weird)
+ * cocoa_display_init() is the "initialize the display" entry point -- this will always be called from on the main thread (strictly, from whichever thread OSX calls our applicationDidFinishLaunching callback on, but I assume that's the main thread)
+ * the runtime entry points into the cocoa UI code are just the functions in the DisplayChangeListener struct: cocoa_update(), cocoa_switch() and cocoa_refresh()
+
+Arranging for the last 3 to schedule their operation onto the main thread is probably what's needed. Things I don't know:
+
+ * should this "run thing on main thread" be synchronous or asynchronous? (sync is probably safest)
+ * what's the right OSX API to do this?
+ * how can we most cleanly do this in a way that still works on OSX 10.6 (the oldest we currently support)? (I suspect we'll need ifdefs and fall back to "just run on this thread" on older versions)
+
+
+I made DisplayChangeListener callbacks dispatch updates to the main thread and it stopped crashing. However, pure Cocoa UI seems non-functional - I can't focus the window, I don't see any application menus, and the fb does not update.
+
+I'm looking at making SDL code thread-safe the same way - because it also calls into Cocoa, and crashes in the same way.
+
+What is the process for submitting PRs to qemu? I'm used to github but I see you use your own git hosting.
+
+Thanks for having a look at this. The cocoa UI does work for me on High Sierra, for what that's worth.
+
+https://wiki.qemu.org/Contribute/SubmitAPatch has our patch submission process.
+
+My feeling on SDL is that this would be a bug to fix in upstream SDL, assuming we're not breaking any "which thread" requirements in the SDL API. It's the job of the SDL abstraction layer to work around host-OS-specific issues. (I didn't realize that the SDL display code worked on OSX QEMU, though -- the only one I've ever used is the Cocoa one, and I would expect anything else to interact weirdly with the way the cocoa UI frontend assumes it's in control.)
+
+
+
+> On Nov 11, 2018, at 2:39 AM, <email address hidden> wrote:
+> 
+> Thanks for the bug report. It looks like Mojave is pickier about apps
+> not calling various GUI update functions from the "wrong" thread. We
+> probably need to figure out how to dispatch those to the main thread
+> instead of whatever thread we were on. Unfortunately we don't really
+> have anybody in QEMU upstream who knows much about OSX or its GUI, and I
+> suspect we don't have anybody with Mojave (my system is still High
+> Sierra and I don't plan to upgrade it for a while); help and patches
+> appreciated from anybody who does...
+
+>  	21  AppKit                              0x00007fff3c019ff8 -[NSWindow setFrame:display:animate:] + 567
+
+I would use the [performSelectorOnMainThread: withObject: waitUntilDone:] method to fix this problem. It should go here in the call stack. I would make the patch myself but I don't know where this call takes place in qemu-system-aarch64.
+
+>  	22  qemu-system-aarch64                 0x000000010b7b2abf qemu-system-aarch64 + 3668671
+
+
+
+Ok I think I found places where code was invalid in Cocoa and fixed it. I can see qemu running my kernel and all interface is responsive. I also believe it should be working on as old as macOS 10.6 machines as well - do you have some CI machines with these versions to test? I don't.
+
+For SDL i didn't look into the details yet. Will try to set up a reproducible case for SDL2 folks over the week.
+
+Will send the patches to mailing list as suggested.
+
+Patches emailed.
+
+Changes reviewable in a decent web-ui here - https://github.com/qemu/qemu/compare/master...berkus:mojave-cocoa-fix?expand=1
+
+http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01941.html thread
+
+Could I ask you to make a debug build of QEMU (configure with --enable-debug) of the current git master, and recreate the backtrace that you quoted in your report, but with the debug symbols? I'm trying to figure out exactly what we're doing on what threads right now, and it would be very helpful to find out what threads are doing what. Specifically, could you do this with the cocoa UI (not SDL) and give a backtrace of all threads at the point where the assert hits, please?
+
+
+Ok, will do.
+
+
+I've had a report from another user that the OSX GUI code works fine for them on Mojave, so maybe the problem you're running into here is more specific than just "doesn't work on this OS". That backtrace might help in narrowing down what is different for you.
+
+
+Can you try to build it without SDL/GTK support? I'm not having any issues with Cocoa display.
+
+I tried building the latest git master and get weird results - it seems to
+work, at least not crashing with any checks that were there before (built
+using plain cocoa ui, no sdl or gtk). I will check back at the original
+master that caused me issues and report.
+On Thu, 29 Nov 2018 at 16:46, Peter Maydell <email address hidden>
+wrote:
+
+> I've had a report from another user that the OSX GUI code works fine for
+> them on Mojave, so maybe the problem you're running into here is more
+> specific than just "doesn't work on this OS". That backtrace might help
+> in narrowing down what is different for you.
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1802684
+>
+> Title:
+>   QEMU gui crashes on macOS Mojave
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1802684/+subscriptions
+>
+
+
+I've tried to run two x86 guests with Cocoa display on 3.1 rc3, the GUI doesn't crash. I've tried to change screen resolution on openSUSE 15, it also works without an issue.
+
+My command line is:
+./x86_64-softmmu/qemu-system-x86_64 -accel hvf -cpu host -hda /path/to/disk -m MEMORY
+
+https://<email address hidden>/ is an RFC patchset which tries to address all the locking issues and make the main thread run only the Cocoa UI event loop, with no blocking operations in UI event callbacks. It's RFC because (as noted in the last two comments) it's not clear any more if it's a necessary refactoring.
+
+We think we have shaken all the bugs out of the patchset which overhauls the Cocoa UI, so the crashes on OSX Mojave should be fixed in QEMU git master; these will be in QEMU 4.0.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1804323 b/results/classifier/zero-shot/118/peripherals/1804323
new file mode 100644
index 00000000..d69307f4
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1804323
@@ -0,0 +1,172 @@
+peripherals: 0.813
+user-level: 0.795
+risc-v: 0.790
+device: 0.772
+virtual: 0.768
+KVM: 0.767
+VMM: 0.766
+mistranslation: 0.765
+hypervisor: 0.760
+register: 0.748
+vnc: 0.742
+permissions: 0.735
+graphic: 0.730
+ppc: 0.728
+performance: 0.717
+x86: 0.716
+debug: 0.706
+TCG: 0.693
+network: 0.679
+socket: 0.673
+boot: 0.660
+arm: 0.655
+i386: 0.651
+files: 0.641
+assembly: 0.640
+semantic: 0.639
+PID: 0.608
+architecture: 0.596
+kernel: 0.586
+
+qemu segfaults in virtio-scsi driver if underlying device returns -EIO
+
+Reported downstream in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1650975
+
+Using qemu from git and reasonably recent nbdkit, this command injects -EIO
+errors into the block device which virtio-scsi is reading from:
+
+$ nbdkit --filter=error memory size=64M error-rate=100% \
+    --run 'x86_64-softmmu/qemu-system-x86_64 -device virtio-scsi,id=scsi -drive file=$nbd,format=raw,id=hd0,if=none -device scsi-hd,drive=hd0'
+nbdkit: memory[1]: error: injecting EIO error into pread
+nbdkit: memory[1]: error: injecting EIO error into pread
+qemu-system-x86_64: hw/scsi/scsi-bus.c:1374: scsi_req_complete: Assertion `req->status == -1' failed.
+
+The stack trace is:
+
+Thread 5 (Thread 0x7f33e1f8b700 (LWP 10474)):
+#0  0x00007f33fe0bf371 in __GI___poll (fds=0x559b07199490, nfds=1, timeout=-1)
+    at ../sysdeps/unix/sysv/linux/poll.c:29
+#1  0x00007f34061df5e6 in  () at /lib64/libglib-2.0.so.0
+#2  0x00007f34061df710 in g_main_context_iteration ()
+    at /lib64/libglib-2.0.so.0
+#3  0x00007f34061df761 in  () at /lib64/libglib-2.0.so.0
+#4  0x00007f34062086ea in  () at /lib64/libglib-2.0.so.0
+#5  0x00007f33fe19b58e in start_thread (arg=<optimized out>)
+    at pthread_create.c:486
+#6  0x00007f33fe0ca593 in clone ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+Thread 4 (Thread 0x7f33e3fff700 (LWP 10473)):
+#0  0x00007f33fe1a4a8d in __lll_lock_wait ()
+    at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
+#1  0x00007f33fe19ddf8 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x559b054697a0 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:78
+#2  0x0000559b04f6b103 in qemu_mutex_lock_impl (mutex=0x559b054697a0 <qemu_global_mutex>, file=0x559b04f87041 "/home/rjones/d/qemu/exec.c", line=3197)
+    at util/qemu-thread-posix.c:66
+#3  0x0000559b04b722ee in qemu_mutex_lock_iothread_impl (file=file@entry=0x559b04f87041 "/home/rjones/d/qemu/exec.c", line=line@entry=3197)
+    at /home/rjones/d/qemu/cpus.c:1845
+#4  0x0000559b04b31859 in prepare_mmio_access (mr=<optimized out>, mr=<optimized out>) at /home/rjones/d/qemu/exec.c:3197
+#5  0x0000559b04b381d4 in address_space_ldub (as=<optimized out>, addr=<optimized out>, attrs=..., result=result@entry=0x0)
+    at /home/rjones/d/qemu/memory_ldst.inc.c:188
+#6  0x0000559b04c61cd0 in helper_inb (env=<optimized out>, port=<optimized out>) at /home/rjones/d/qemu/target/i386/cpu.h:1846
+#7  0x00007f33e889dc3e in code_gen_buffer ()
+#8  0x0000559b04bb3b87 in cpu_tb_exec (itb=<optimized out>, cpu=0x7f33e8876100 <code_gen_buffer+684243>) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:171
+#9  0x0000559b04bb3b87 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7f33e8876100 <code_gen_buffer+684243>) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:615
+#10 0x0000559b04bb3b87 in cpu_exec (cpu=cpu@entry=0x559b05db57a0)
+    at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:725
+#11 0x0000559b04b7088f in tcg_cpu_exec (cpu=0x559b05db57a0)
+    at /home/rjones/d/qemu/cpus.c:1425
+#12 0x0000559b04b72c03 in qemu_tcg_cpu_thread_fn (arg=0x559b05db57a0)
+    at /home/rjones/d/qemu/cpus.c:1729
+#13 0x0000559b04b72c03 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x559b05db57a0)
+    at /home/rjones/d/qemu/cpus.c:1703
+#14 0x0000559b04f6afba in qemu_thread_start (args=<optimized out>)
+    at util/qemu-thread-posix.c:498
+#15 0x00007f33fe19b58e in start_thread (arg=<optimized out>)
+    at pthread_create.c:486
+#16 0x00007f33fe0ca593 in clone ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+Thread 3 (Thread 0x7f33e178a700 (LWP 10475)):
+#0  0x00007f33fe0bf371 in __GI___poll (fds=0x559b071aa760, nfds=2, timeout=-1)
+    at ../sysdeps/unix/sysv/linux/poll.c:29
+#1  0x00007f34061df5e6 in  () at /lib64/libglib-2.0.so.0
+#2  0x00007f34061df9a2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
+#3  0x00007f34032ca90a in  () at /lib64/libgio-2.0.so.0
+#4  0x00007f34062086ea in  () at /lib64/libglib-2.0.so.0
+#5  0x00007f33fe19b58e in start_thread (arg=<optimized out>)
+    at pthread_create.c:486
+#6  0x00007f33fe0ca593 in clone ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+Thread 2 (Thread 0x7f33eb050700 (LWP 10471)):
+#0  0x00007f33fe1a5400 in __GI___nanosleep (requested_time=0x7f33eb04d270, remaining=0x7f33eb04d280) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
+#1  0x00007f3406209e17 in g_usleep () at /lib64/libglib-2.0.so.0
+#2  0x0000559b04f7cb80 in call_rcu_thread (opaque=opaque@entry=0x0)
+    at util/rcu.c:253
+#3  0x0000559b04f6afba in qemu_thread_start (args=<optimized out>)
+    at util/qemu-thread-posix.c:498
+#4  0x00007f33fe19b58e in start_thread (arg=<optimized out>)
+    at pthread_create.c:486
+#5  0x00007f33fe0ca593 in clone ()
+    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+Thread 1 (Thread 0x7f33eb9b42c0 (LWP 10470)):
+#0  0x00007f33fe00553f in __GI_raise (sig=sig@entry=6)
+    at ../sysdeps/unix/sysv/linux/raise.c:50
+#1  0x00007f33fdfef895 in __GI_abort () at abort.c:79
+#2  0x00007f33fdfef769 in __assert_fail_base (fmt=0x7f33fe156ea8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x559b050203cf "req->status == -1", file=0x559b050203aa "hw/scsi/scsi-bus.c", line=1374, function=0x559b05020dc0 <__PRETTY_FUNCTION__.32414> "scsi_req_complete") at assert.c:92
+#3  0x00007f33fdffd9f6 in __GI___assert_fail (assertion=assertion@entry=0x559b050203cf "req->status == -1", file=file@entry=0x559b050203aa "hw/scsi/scsi-bus.c", line=line@entry=1374, function=function@entry=0x559b05020dc0 <__PRETTY_FUNCTION__.32414> "scsi_req_complete") at assert.c:101
+#4  0x0000559b04da23c0 in scsi_req_complete (req=<optimized out>, status=<optimized out>) at hw/scsi/scsi-bus.c:1374
+#5  0x0000559b04d9cc60 in scsi_dma_complete_noio (r=0x559b069c3600, ret=<optimized out>) at hw/scsi/scsi-disk.c:281
+#6  0x0000559b04d9cd0f in scsi_dma_complete (opaque=0x559b069c3600, ret=-5)
+    at hw/scsi/scsi-disk.c:302
+#7  0x0000559b04c91607 in dma_complete (ret=-5, dbs=0x559b07808000)
+    at dma-helpers.c:116
+#8  0x0000559b04c91607 in dma_blk_cb (opaque=0x559b07808000, ret=-5)
+    at dma-helpers.c:138
+#9  0x0000559b04ec411e in blk_aio_complete (acb=0x559b07514fa0)
+    at block/block-backend.c:1345
+#10 0x0000559b04f7e32b in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:116
+#11 0x00007f33fe01b200 in __start_context ()
+    at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91
+#12 0x00007ffc0896b040 in  ()
+#13 0x0000000000000000 in  ()
+
+I bisected this to:
+
+40dce4ee61c68395f6d463fae792f61b7c003bce is the first bad commit
+commit 40dce4ee61c68395f6d463fae792f61b7c003bce
+Author: Paolo Bonzini <email address hidden>
+Date:   Sat Oct 13 11:52:34 2018 +0200
+
+    scsi-disk: fix rerror/werror=ignore
+    
+    rerror=ignore was returning true from scsi_handle_rw_error but the callers were not
+    calling scsi_req_complete when rerror=ignore returns true (this is the correct thing
+    to do when true is returned after executing a passthrough command).  Fix this by
+    calling it in scsi_handle_rw_error.
+    
+    Signed-off-by: Paolo Bonzini <email address hidden>
+
+:040000 040000 311386b9b91d77840a849459ab6ae41a37fd7f42 8adcda67d7487bcc18966f096c9923da3b8dc0b9 M	hw
+
+Kevin suggested this change, which works for me:
+
+diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
+index 6eb258d3f3..0e9027c8f3 100644
+--- a/hw/scsi/scsi-disk.c
++++ b/hw/scsi/scsi-disk.c
+@@ -482,7 +482,7 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int error, bool acct_failed)
+     if (action == BLOCK_ERROR_ACTION_STOP) {
+         scsi_req_retry(&r->req);
+     }
+-    return false;
++    return true;
+ }
+ 
+ static void scsi_write_complete_noio(SCSIDiskReq *r, int ret)
+
+
+The fix as suggested in comment 1 is now in QEMU master as commit 1c7f618f689b0b5; this is in 3.1.0-rc3 and will be in the final 3.1 release.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1828508 b/results/classifier/zero-shot/118/peripherals/1828508
new file mode 100644
index 00000000..c3514d7e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1828508
@@ -0,0 +1,125 @@
+peripherals: 0.883
+semantic: 0.880
+register: 0.878
+hypervisor: 0.871
+user-level: 0.867
+assembly: 0.866
+graphic: 0.860
+VMM: 0.860
+debug: 0.850
+mistranslation: 0.846
+performance: 0.845
+TCG: 0.840
+virtual: 0.839
+arm: 0.837
+architecture: 0.837
+socket: 0.836
+KVM: 0.833
+device: 0.831
+PID: 0.830
+permissions: 0.828
+risc-v: 0.825
+vnc: 0.809
+ppc: 0.805
+kernel: 0.797
+network: 0.792
+files: 0.784
+boot: 0.768
+x86: 0.750
+i386: 0.556
+
+qemu-img created VMDK files lead to "Unsupported or invalid disk type 7"
+
+Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a Windows 10 machine.
+
+Converting a VHD to VMDK.
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk"
+
+I have also tried:
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk"
+
+Attaching the VMDK to a VM in VMware produces the following error when powering on.
+
+Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+Target: MyVM1
+vCenter Server: VCENTER
+Error Stack
+An error was received from the ESX host while powering on VM MyVM1.
+Failed to start the virtual machine.
+Module DevicePowerOn power on failed. 
+Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' 
+Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+
+
+If I do not specify the adapter type, it creates an IDE VMDK which works perfectly.
+
+On Fri, May 10, 2019 at 06:06:32AM -0000, Jake Mikelson wrote:
+> Public bug reported:
+> 
+> Using qemu-img version 3.1.50 (v3.1.0-13607-geb2db0f7ba-dirty) on a
+> Windows 10 machine.
+> 
+> Converting a VHD to VMDK.
+> qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic -p "c:\test\AppD-VM01.vmdk"
+> 
+> I have also tried:
+> qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=buslogic,hwversion=6 -p "c:\test\AppD-VM01.vmdk"
+> 
+> Attaching the VMDK to a VM in VMware produces the following error when
+> powering on.
+> 
+> Power On virtual machine:Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+> Target: MyVM1
+> vCenter Server: VCENTER
+> Error Stack
+> An error was received from the ESX host while powering on VM MyVM1.
+> Failed to start the virtual machine.
+> Module DevicePowerOn power on failed. 
+> Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk' 
+> Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+> 
+> 
+> If I do not specify the adapter type, it creates an IDE VMDK which works perfectly.
+> 
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+> 
+> -- 
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1828508
+
+Which version of VMware are you running?
+
+Stefan
+
+
+Hi, I'm running 5.5.
+
+I've been playing around with some of the options, and if I run the below, I end up with 2 files.
+
+qemu-img.exe convert "c:\test\AppD-VM01.vhd" -O vmdk -o adapter_type=lsilogic,subformat=monolithicFlat -p "c:\test\AppD-VM01.vmdk"
+
+The files I get are:
+AppD-VM01.vmdk (which is always 12kb)
+AppD-VM01-flat.vmdk (which is the full size of the disk, eg 30GB).
+
+If I then upload both of these files to the datastore, they somehow merge into 1 and I can attach and power on the VM. If you dont upload both files into the datastore, VMware does not recognise it.
+
+This is the only method that seems to work for me.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/183 b/results/classifier/zero-shot/118/peripherals/183
new file mode 100644
index 00000000..fc874d1b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/183
@@ -0,0 +1,31 @@
+peripherals: 0.891
+device: 0.759
+architecture: 0.727
+permissions: 0.591
+performance: 0.534
+network: 0.531
+mistranslation: 0.461
+semantic: 0.425
+assembly: 0.419
+graphic: 0.407
+user-level: 0.338
+ppc: 0.269
+PID: 0.262
+virtual: 0.241
+debug: 0.229
+files: 0.163
+i386: 0.120
+boot: 0.118
+TCG: 0.093
+vnc: 0.069
+register: 0.064
+socket: 0.056
+VMM: 0.054
+hypervisor: 0.042
+arm: 0.042
+risc-v: 0.028
+x86: 0.015
+kernel: 0.014
+KVM: 0.010
+
+Cannot use usb-host on Mac OS
diff --git a/results/classifier/zero-shot/118/peripherals/1833204 b/results/classifier/zero-shot/118/peripherals/1833204
new file mode 100644
index 00000000..ae2f945b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1833204
@@ -0,0 +1,154 @@
+peripherals: 0.902
+hypervisor: 0.870
+user-level: 0.866
+KVM: 0.860
+TCG: 0.854
+mistranslation: 0.853
+VMM: 0.841
+ppc: 0.841
+register: 0.837
+vnc: 0.827
+risc-v: 0.824
+x86: 0.785
+device: 0.769
+graphic: 0.739
+performance: 0.739
+virtual: 0.731
+permissions: 0.730
+arm: 0.729
+semantic: 0.727
+boot: 0.690
+debug: 0.689
+socket: 0.655
+i386: 0.655
+architecture: 0.654
+kernel: 0.638
+assembly: 0.638
+files: 0.632
+network: 0.629
+PID: 0.621
+
+VM failed to start in nested virtualization with error "KVM: entry failed, hardware error 0x0"
+
+Hi,
+
+I have 3 ubuntu nodes provisioned by IaaS. 
+Then I tried to launch VM again in my ubuntu nodes.
+It's a little strange that VM could be started successfully in two nodes. 
+And always failed in one nodes with error "KVM: entry failed, hardware error 0x0". 
+
+When using virsh to resume the VM, it failed with following error,
+virsh # list
+ Id   Name                State
+----------------------------------
+ 1    default_vm-cirros   paused
+
+virsh # resume default_vm-cirros
+error: Failed to resume domain default_vm-cirros
+error: internal error: unable to execute QEMU command 'cont': Resetting the Virtual Machine is required
+
+
+The detailed log from /var/log/libvirt/qemu/default_vm-cirros.log is as below.
+```
+2019-06-18 09:55:52.397+0000: starting up libvirt version: 5.0.0, package: 1.fc28 (Unknown, 2019-01-22-08:04:34, 64723eea657e48d296e6beb0b1be9c4c), qemu version: 3.1.0qemu-3.1.0-4.fc28, kernel: 4.15.0-47-generic, hostname: vm-cirros
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
+HOME=/root \
+QEMU_AUDIO_DRV=none \
+/usr/bin/qemu-system-x86_64 \
+-name guest=default_vm-cirros,debug-threads=on \
+-S \
+-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-default_vm-cirros/master-key.aes \
+-machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off \
+-cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc_adjust=on,mpx=on,avx512f=on,avx512cd=on,ssbd=on,xsaveopt=on,abm=on,invpcid=off \
+-m 489 \
+-realtime mlock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-object iothread,id=iothread1 \
+-uuid 0d2a2043-41c0-59c3-9b17-025022203668 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=22,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
+-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
+-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
+-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
+-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x0 \
+-drive file=/var/run/kubevirt-ephemeral-disks/container-disk-data/default/vm-cirros/disk_containerdisk/disk-image.raw,format=raw,if=none,id=drive-ua-containerdisk,cache=none \
+-device virtio-blk-pci,scsi=off,bus=pci.3,addr=0x0,drive=drive-ua-containerdisk,id=ua-containerdisk,bootindex=1,write-cache=on \
+-drive file=/var/run/kubevirt-ephemeral-disks/cloud-init-data/default/vm-cirros/noCloud.iso,format=raw,if=none,id=drive-ua-cloudinitdisk,cache=none \
+-device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-ua-cloudinitdisk,id=ua-cloudinitdisk,write-cache=on \
+-netdev tap,fd=24,id=hostua-default,vhost=on,vhostfd=25 \
+-device virtio-net-pci,host_mtu=1430,netdev=hostua-default,id=ua-default,mac=16:57:38:cd:57:cb,bus=pci.1,addr=0x0 \
+-chardev socket,id=charserial0,fd=26,server,nowait \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-chardev socket,id=charchannel0,fd=27,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
+-vnc vnc=unix:/var/run/kubevirt-private/3b22a138-91af-11e9-af36-0016ac101123/virt-vnc \
+-device VGA,id=video0,vgamem_mb=16,bus=pcie.0,addr=0x1 \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+KVM: entry failed, hardware error 0x0
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306d2
+ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
+EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=06 66 05 00 00 01 00 8e c1 26 66 a3 14 f5 66 5b 66 5e 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+```
+
+Ubuntu node version as follow,
+cat /etc/os-release 
+NAME="Ubuntu"
+VERSION="18.04.2 LTS (Bionic Beaver)"
+ID=ubuntu
+ID_LIKE=debian
+PRETTY_NAME="Ubuntu 18.04.2 LTS"
+VERSION_ID="18.04"
+HOME_URL="https://www.ubuntu.com/"
+SUPPORT_URL="https://help.ubuntu.com/"
+BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
+PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
+VERSION_CODENAME=bionic
+UBUNTU_CODENAME=bionic
+
+Output of `uname -a` is:
+4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+
+
+
+Any additional information needed, please let me know.
+Thx.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1834 b/results/classifier/zero-shot/118/peripherals/1834
new file mode 100644
index 00000000..9c7372af
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1834
@@ -0,0 +1,214 @@
+peripherals: 0.859
+semantic: 0.842
+hypervisor: 0.830
+register: 0.809
+architecture: 0.807
+device: 0.802
+permissions: 0.802
+debug: 0.800
+risc-v: 0.799
+PID: 0.796
+assembly: 0.793
+arm: 0.779
+user-level: 0.778
+virtual: 0.775
+boot: 0.772
+x86: 0.755
+network: 0.728
+kernel: 0.724
+performance: 0.721
+vnc: 0.707
+graphic: 0.707
+VMM: 0.704
+KVM: 0.698
+socket: 0.681
+ppc: 0.651
+TCG: 0.617
+mistranslation: 0.607
+i386: 0.605
+files: 0.517
+
+qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed.
+Description of problem:
+
+Steps to reproduce:
+1. Run qemu using the provided command line
+2. linux kernel boot and qemu crashes at pci bus scan step
+3.
+Additional information:
+```
+SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org
+iPXE (http://ipxe.org) 00:02.0 CA00 PCI2.10 PnP PMM+3EFD0CE0+3EF30CE0 CA00
+iPXE (http://ipxe.org) 00:05.0 CB00 PCI2.10 PnP PMM+3EF1FCE0 3EF30CE0 CB00
+Booting from ROM...
+[    0.000000] Linux version 6.1.38-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.40.0.20230620) #1 SMP PREEMPT_DYNAMIC Thu Jul  6 18:52:54 UTC 2023
+[    0.000000] Command line: console=ttyS0
+[    0.000000] x86/fpu: x87 FPU will use FXSAVE
+[    0.000000] signal: max sigframe size: 1040
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdefff] usable
+[    0.000000] BIOS-e820: [mem 0x000000003ffdf000-0x000000003fffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
+[    0.000000] NX (Execute Disable) protection: active
+[    0.000000] SMBIOS 3.0.0 present.
+[    0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
+[    0.000000] last_pfn = 0x3ffdf max_arch_pfn = 0x400000000
+[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
+[    0.000000] found SMP MP-table at [mem 0x000f5b80-0x000f5b8f]
+[    0.000000] ACPI: Early table checksum verification disabled
+[    0.000000] ACPI: RSDP 0x00000000000F59A0 000014 (v00 BOCHS )
+[    0.000000] ACPI: RSDT 0x000000003FFE238A 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACP 0x000000003FFE217A 0000F4 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: DSDT 0x000000003FFE0040 00213A (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACS 0x000000003FFE0000 000040
+[    0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: FACS 0x000000003FFE0000 000040 
+[    0.000000] ACPI: APIC 0x000000003FFE226E 000080 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: HPET 0x000000003FFE22EE 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: MCFG 0x000000003FFE2326 00003C (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: WAET 0x000000003FFE2362 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+[    0.000000] ACPI: Reserving FACP table memory at [mem 0x3ffe217a-0x3ffe226d]
+[    0.000000] ACPI: Reserving DSDT table memory at [mem 0x3ffe0040-0x3ffe2179]
+[    0.000000] ACPI: Reserving FACS table memory at [mem 0x3ffe0000-0x3ffe003f]
+[    0.000000] ACPI: Reserving APIC table memory at [mem 0x3ffe226e-0x3ffe22ed]
+[    0.000000] ACPI: Reserving HPET table memory at [mem 0x3ffe22ee-0x3ffe2325]
+[    0.000000] ACPI: Reserving MCFG table memory at [mem 0x3ffe2326-0x3ffe2361]
+[    0.000000] ACPI: Reserving WAET table memory at [mem 0x3ffe2362-0x3ffe2389]
+[    0.000000] Zone ranges:
+[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
+[    0.000000]   DMA32    [mem 0x0000000001000000-0x000000003ffdefff]
+[    0.000000]   Normal   empty
+[    0.000000]   Device   empty
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009efff]
+[    0.000000]   node   0: [mem 0x0000000000100000-0x000000003ffdefff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000003ffdefff]
+[    0.000000] On node 0, zone DMA: 1 pages in unavailable ranges
+[    0.000000] On node 0, zone DMA: 97 pages in unavailable ranges
+[    0.000000] On node 0, zone DMA32: 33 pages in unavailable ranges
+[    0.000000] ACPI: PM-Timer IO Port: 0x608
+[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
+[    0.000000] IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
+[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
+[    0.000000] ACPI: Using ACPI (MADT) for SMP configuration information
+[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
+[    0.000000] smpboot: Allowing 2 CPUs, 0 hotplug CPUs
+[    0.000000] [mem 0x40000000-0xafffffff] available for PCI devices
+[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:2 nr_cpu_ids:2 nr_node_ids:1
+[    0.000000] percpu: Embedded 52 pages/cpu s173288 r8192 d31512 u1048576
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 257759
+[    0.000000] Kernel command line: console=ttyS0
+[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
+[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
+[    0.000000] Memory: 1002116K/1048052K available (12294K kernel code, 1469K rwdata, 2600K rodata, 1488K init, 2040K bss, 45680K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
+[    0.000000] ftrace: allocating 31276 entries in 123 pages
+[    0.000000] ftrace: allocated 123 pages with 6 groups
+[    0.000000] ftrace: allocating 31276 entries in 123 pages
+[    0.000000] ftrace: allocated 123 pages with 6 groups
+[    0.000000] Dynamic Preempt: none
+[    0.000000] rcu: Preemptible hierarchical RCU implementation.
+[    0.000000] rcu:     RCU event tracing is enabled.
+[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
+[    0.000000]  Trampoline variant of Tasks RCU enabled.
+[    0.000000]  Rude variant of Tasks RCU enabled.
+[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
+[    0.000000] NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16
+[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
+[    0.000000] Console: colour VGA+ 80x25
+[    0.000000] printk: console [ttyS0] enabled
+[    0.000000] ACPI: Core revision 20220331
+[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns
+[    0.020000] APIC: Switch to symmetric I/O mode setup
+[    0.040000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
+[    0.120000] tsc: Unable to calibrate against PIT
+[    0.120000] tsc: using HPET reference calibration
+[    0.120000] tsc: Detected 2299.960 MHz processor
+[    0.001362] tsc: Marking TSC unstable due to TSCs unsynchronized
+[    0.002851] Calibrating delay loop (skipped), value calculated using timer frequency.. 4599.92 BogoMIPS (lpj=22999600)
+[    0.004441] pid_max: default: 32768 minimum: 301
+[    0.019780] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.020332] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
+[    0.078474] process: using AMD E400 aware idle routine
+[    0.079221] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.079631] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.081092] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.082698] Spectre V2 : Mitigation: Retpolines
+[    0.083053] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.083616] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
+[    0.348864] Freeing SMP alternatives memory: 32K
+[    0.514732] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
+[    0.536546] cblist_init_generic: Setting adjustable number of callback queues.
+[    0.537604] cblist_init_generic: Setting shift to 1 and lim to 1.
+[    0.538995] cblist_init_generic: Setting shift to 1 and lim to 1.
+[    0.541338] Performance Events: PMU not available due to virtualization, using software events only.
+[    0.548504] rcu: Hierarchical SRCU implementation.
+[    0.548986] rcu:     Max phase no-delay instances is 1000.
+[    0.563842] smp: Bringing up secondary CPUs ...
+[    0.583950] x86: Booting SMP configuration:
+[    0.584395] .... node  #0, CPUs:      #1
+[    0.802667] smp: Brought up 1 node, 2 CPUs
+[    0.803300] smpboot: Max logical packages: 1
+[    0.803821] smpboot: Total of 2 processors activated (9202.49 BogoMIPS)
+[    0.864556] devtmpfs: initialized
+[    0.897545] x86/mm: Memory block size: 128MB
+[    0.936982] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[    0.938878] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
+[    0.980994] NET: Registered PF_NETLINK/PF_ROUTE protocol family
+[    1.004001] thermal_sys: Registered thermal governor 'step_wise'
+[    1.004143] thermal_sys: Registered thermal governor 'user_space'
+[    1.009528] cpuidle: using governor menu
+[    1.022723] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
+[    1.043717] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000)
+[    1.050546] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820
+[    1.060576] PCI: Using configuration type 1 for base access
+[    1.074215] mtrr: your CPUs had inconsistent fixed MTRR settings
+[    1.075157] mtrr: your CPUs had inconsistent variable MTRR settings
+[    1.076043] mtrr: your CPUs had inconsistent MTRRdefType settings
+[    1.076840] mtrr: probably your BIOS does not setup all CPUs.
+[    1.077612] mtrr: corrected configuration.
+[    1.453630] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
+[    1.454286] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
+[    1.467152] raid6: skipped pq benchmark and selected sse2x4
+[    1.467152] raid6: using intx1 recovery algorithm
+[    1.485004] ACPI: Added _OSI(Module Device)
+[    1.485539] ACPI: Added _OSI(Processor Device)
+[    1.485909] ACPI: Added _OSI(3.0 _SCP Extensions)
+[    1.486309] ACPI: Added _OSI(Processor Aggregator Device)
+[    1.578101] ACPI: 1 ACPI AML tables successfully acquired and loaded
+[    1.670966] ACPI: Interpreter enabled
+[    1.676848] ACPI: PM: (supports S0 S3 S5)
+[    1.677404] ACPI: Using IOAPIC for interrupt routing
+[    1.683268] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
+[    1.684107] PCI: Using E820 reservations for host bridge windows
+[    1.691382] ACPI: Enabled 2 GPEs in block 00 to 3F
+[    1.828171] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
+[    1.831923] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
+[    1.839401] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR DPC]
+[    1.843631] acpi PNP0A08:00: _OSC: OS now controls [SHPCHotplug PME AER PCIeCapability]
+[    1.867627] PCI host bridge to bus 0000:00
+[    1.868866] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
+[    1.870044] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
+[    1.870572] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
+[    1.871151] pci_bus 0000:00: root bus resource [mem 0x40000000-0xafffffff window]
+[    1.871719] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
+[    1.872269] pci_bus 0000:00: root bus resource [mem 0x100000000-0x8ffffffff window]
+[    1.873668] pci_bus 0000:00: root bus resource [bus 00-ff]
+[    1.880983] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
+[    1.898659] pci 0000:00:01.0: [1234:1111] type 00 class 0x030000
+qemu-system-x86_64: ../hw/pci/msix.c:227: msix_table_mmio_write: Assertion `addr + size <= dev->msix_entries_nr * PCI_MSIX_ENTRY_SIZE' failed.
+```
diff --git a/results/classifier/zero-shot/118/peripherals/1835466 b/results/classifier/zero-shot/118/peripherals/1835466
new file mode 100644
index 00000000..c20d5d5b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1835466
@@ -0,0 +1,280 @@
+peripherals: 0.874
+KVM: 0.872
+vnc: 0.850
+hypervisor: 0.836
+x86: 0.818
+user-level: 0.803
+VMM: 0.802
+TCG: 0.790
+virtual: 0.786
+mistranslation: 0.773
+ppc: 0.759
+risc-v: 0.752
+debug: 0.747
+performance: 0.746
+register: 0.744
+graphic: 0.737
+device: 0.732
+i386: 0.730
+permissions: 0.722
+arm: 0.714
+semantic: 0.702
+architecture: 0.699
+files: 0.696
+assembly: 0.688
+socket: 0.687
+network: 0.676
+PID: 0.673
+kernel: 0.655
+boot: 0.633
+
+qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?)
+
+After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release tarball), I'm seeing a (reproducible) crash related to audio subsystem.
+
+I recompiled qemu with debugging options and got it to crash under gdb:
+
+Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted.
+0x00007ffff52e420b in raise () from /lib64/libc.so.6
+(gdb) bt
+#0  0x00007ffff52e420b in raise () at /lib64/libc.so.6
+#1  0x00007ffff52c6524 in abort () at /lib64/libc.so.6
+#2  0x000000000041ec33 in audio_get_pdo_in (dev=<optimized out>) at audio/audio_template.h:328
+#3  0x00000000005d0123 in AUD_open_in
+    (card=0x7ffdde98dbc8, sw=0x7ffff17444e0, name=0x999d80 "adc", callback_opaque=callback_opaque@entry=0x7ffdde98fd58, callback_fn=0x610940 <hda_audio_input_cb>, as=as@entry=0x7ffdde98fd84) at audio/audio_template.h:434
+#4  0x000000000060fe2e in hda_audio_setup (st=0x7ffdde98fd58) at hw/audio/hda-codec.c:490
+#5  0x000000000061051b in hda_audio_command (hda=0x7ffdde98db40, nid=4, data=<optimized out>) at hw/audio/hda-codec.c:590
+#6  0x000000000060ea20 in intel_hda_send_command (d=d@entry=0x7ffff0a2fc00, verb=verb@entry=4341777) at hw/audio/intel-hda.c:301
+#7  0x000000000060ebbe in intel_hda_corb_run (d=<optimized out>) at hw/audio/intel-hda.c:336
+#8  0x000000000060ebbe in intel_hda_corb_run (d=0x7ffff0a2fc00) at hw/audio/intel-hda.c:305
+#9  0x0000000000495b99 in memory_region_write_accessor
+    (mr=mr@entry=0x7ffff0a307a0, addr=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, shift=<optimized out>, mask=mask@entry=65535, attrs=...)
+    at memory.c:502
+#10 0x000000000049448e in access_with_adjusted_size
+    (addr=addr@entry=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x495b10 <memory_region_write_accessor>, mr=0x7ffff0a307a0, attrs=...) at memory.c:568
+#11 0x00000000004974f3 in memory_region_dispatch_write (mr=mr@entry=0x7ffff0a307a0, addr=72, data=<optimized out>, size=2, attrs=attrs@entry=...)
+    at memory.c:1496
+#12 0x000000000042afbc in flatview_write_continue
+    (fv=fv@entry=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x7ffff0a307a0) at exec.c:3279
+#13 0x000000000042b1d6 in flatview_write
+    (fv=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2)
+    at exec.c:3318
+#14 0x000000000042e2a6 in address_space_write
+    (as=0xfc5080 <address_space_memory>, addr=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=2)
+    at exec.c:3408
+#15 0x000000000042e33a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., 
+    attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=<optimized out>, is_write=<optimized out>) at exec.c:3419
+#16 0x00000000004ac3c6 in kvm_cpu_exec (cpu=cpu@entry=0x7ffff0a81140) at accel/kvm/kvm-all.c:2034
+#17 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=0x7ffff0a81140) at cpus.c:1281
+#18 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x7ffff0a81140) at cpus.c:1254
+#19 0x000000000089d0eb in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:502
+#20 0x00007ffff549319c in start_thread () at /lib64/libpthread.so.0
+#21 0x00007ffff53ba4af in clone () at /lib64/libc.so.6
+
+
+After some poking around, I think there's something overwriting dev->driver so this switch(dev->driver) statement falls through to abort(): https://git.qemu.org/?p=qemu.git;a=blob;f=audio/audio_template.h;h=1232bb54db0e7073e60e3ccb72c1ed72cf5e3831;hb=131b9a05705636086699df15d4a6d328bb2585e8#l304
+
+
+Here's why I think so:
+
+$ export QEMU_AUDIO_DRV=pa
+$ gdb /usr/bin/qemu-system-x86_64
+(gdb) b qpa_audio_init
+Breakpoint 1 at 0x79bcb0: file audio/paaudio.c, line 831.
+(gdb) b audio_get_pdo_in
+Breakpoint 2 at 0x5ce320: file audio/audio_template.h, line 304.
+(gdb) run -enable-kvm -cpu Nehalem -machine q35 -device intel-iommu -name Workstation -smp 4 -m 8G -soundhw hda -rtc base=localtime -drive file=workstation-disk0.qcow2,if=virtio,format=qcow2 -drive file=workstation-disk1.qcow2,if=virtio,format=qcow2 -net nic,model=virtio,macaddr=aa:bb:cc:dd:ee:ff -net tap,ifname=tap42 -monitor telnet:127.0.0.1:7043,server,nowait -pidfile workstation.pid -vga qxl -global qxl-vga.vgamem_mb=64 -device usb-ehci,id=ehci -device usb-host,vendorid=0x1390,productid=0x5454,bus=ehci.0 -device usb-host,vendorid=0x054c,bus=ehci.0 -device usb-tablet -device nec-usb-xhci,id=xhci -device usb-host,vendorid=0x10c4,productid=0x888e,bus=xhci.0
+
+Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831
+(gdb) p (*dev)->driver
+$1 = AUDIODEV_DRIVER_PA
+(gdb) p/d AUDIODEV_DRIVER_PA
+$2 = 5
+(gdb) cont
+Continuing.
+[Thread 0x7ffff09ff700 (LWP 4078) exited]
+audio: warning: Using timer based audio emulation
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304
+(gdb) p (*dev)->driver
+$3 = AUDIODEV_DRIVER_PA
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304
+(gdb) p (*dev)->driver
+$4 = AUDIODEV_DRIVER_PA
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304
+(gdb) p (*dev)->driver
+$5 = AUDIODEV_DRIVER_PA
+(gdb) cont
+Continuing.
+[New Thread 0x7ffff09ff700 (LWP 4483)]
+[New Thread 0x7ffddcdff700 (LWP 4489)]
+[New Thread 0x7ffddbdff700 (LWP 4490)]
+[New Thread 0x7ffddb1ff700 (LWP 4491)]
+[New Thread 0x7ffdd2dff700 (LWP 4494)]
+[New Thread 0x7ffdd25fe700 (LWP 4495)]
+[New Thread 0x7ffdd1dfd700 (LWP 4497)]
+[New Thread 0x7ffdda5ff700 (LWP 4500)]
+[New Thread 0x7ffdcedff700 (LWP 4501)]
+qemu-system-x86_64: warning: guest updated active QH
+[Switching to Thread 0x7fffef7ff700 (LWP 4097)]
+
+Thread 4 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304
+(gdb) p (*dev)->driver
+$6 = 176
+
+
+For what it's worth, guest is Fedora 29, host is a Slackware system with qemu compiled (manually) with these options:
+
+CFLAGS="-O2 -fPIC" \
+CXXFLAGS="-O2 -fPIC" \
+./configure \
+  --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var \
+  --enable-gtk \
+  --enable-system \
+  --enable-kvm \
+  --enable-virtfs \
+  --enable-sdl \
+  --enable-gnutls \
+  --enable-curses \
+  --enable-virtfs \
+  --enable-curl \
+  --enable-linux-aio \
+  --enable-vhost-net \
+  --enable-spice \
+  --enable-libusb \
+  --enable-usb-redir \
+  --enable-lzo \
+  --enable-bzip2 \
+  --enable-libssh2 \
+  --enable-numa \
+  --enable-jemalloc \
+  --enable-opengl \
+  --audio-drv-list=alsa,oss,sdl,pa \
+  --enable-vnc --enable-vnc-sasl --enable-vnc-png --enable-vnc-jpeg \
+  --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user,arm-softmmu,arm-linux-user,armeb-linux-user,sparc64-softmmu,sparc-softmmu,sparc32plus-linux-user,sparc64-linux-user \
+  --enable-debug --extra-cflags="-g3" --extra-ldflags="-g3" --disable-strip --disable-pie  # For debugging only
+
+Can you set a watchpoint for (*dev)->driver and see where it fires?
+
+My gdb-fu isn't great - does the following help?
+
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	audio/audio_template.h: No such file or directory.
+(gdb) print (*dev)->driver
+$1 = AUDIODEV_DRIVER_PA
+(gdb) watch *0x7ffff161b6a0
+Hardware watchpoint 4: *0x7ffff161b6a0
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	in audio/audio_template.h
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=dev@entry=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	in audio/audio_template.h
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831
+831	audio/paaudio.c: No such file or directory.
+(gdb) cont
+Continuing.
+audio: warning: Using timer based audio emulation
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	audio/audio_template.h: No such file or directory.
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	in audio/audio_template.h
+(gdb) cont
+Continuing.
+
+Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	in audio/audio_template.h
+(gdb) p (*dev)->driver
+$2 = AUDIODEV_DRIVER_PA
+(gdb) cont
+Continuing.
+[New Thread 0x7ffff09ff700 (LWP 6438)]
+[New Thread 0x7ffddcdff700 (LWP 6439)]
+
+Thread 1 "qemu-system-x86" hit Hardware watchpoint 4: *0x7ffff161b6a0
+
+Old value = -486628296
+New value = 0
+0x00007ffff5422cf0 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6
+(gdb) bt
+#0  0x00007ffff5422cf0 in __memset_avx2_unaligned_erms () at /lib64/libc.so.6
+#1  0x00007ffff580cee3 in calloc () at /usr/lib64/libjemalloc.so.2
+#2  0x00007ffff7ac9db1 in g_malloc0 () at /usr/lib64/libglib-2.0.so.0
+#3  0x00007ffff7bc7cc9 in  () at /usr/lib64/libgobject-2.0.so.0
+#4  0x00007ffff7bca8b8 in g_type_register_static () at /usr/lib64/libgobject-2.0.so.0
+#5  0x00007ffff7bca94d in g_type_register_static_simple () at /usr/lib64/libgobject-2.0.so.0
+#6  0x00007ffff7040e3a in  () at /usr/lib64/libgtk-3.so.0
+#7  0x00007ffff7043865 in gtk_icon_theme_get_type () at /usr/lib64/libgtk-3.so.0
+#8  0x00007ffff7043889 in gtk_icon_theme_new () at /usr/lib64/libgtk-3.so.0
+#9  0x00007ffff7043aa5 in gtk_icon_theme_get_for_screen () at /usr/lib64/libgtk-3.so.0
+#10 0x00000000007a0df3 in gtk_display_init (ds=<optimized out>, opts=0xfe7ae0 <dpy>) at ui/gtk.c:2200
+#11 0x0000000000423dd8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4532
+(gdb) 
+(gdb) cont
+Continuing.
+[Thread 0x7ffddcdff700 (LWP 6439) exited]
+
+Thread 1 "qemu-system-x86" hit Hardware watchpoint 4: *0x7ffff161b6a0
+
+Old value = 0
+New value = -245161264
+0x00007ffff7bc7de1 in ?? () from /usr/lib64/libgobject-2.0.so.0
+(gdb) cont
+Continuing.
+[New Thread 0x7ffddcdff700 (LWP 6507)]
+[New Thread 0x7ffddbbff700 (LWP 6508)]
+[New Thread 0x7ffdd85ff700 (LWP 6509)]
+[New Thread 0x7ffdd25ff700 (LWP 6510)]
+[New Thread 0x7ffdd1dfe700 (LWP 6511)]
+[New Thread 0x7ffdd15fd700 (LWP 6512)]
+[New Thread 0x7ffddaafa700 (LWP 6513)]
+[New Thread 0x7ffdce7ff700 (LWP 6514)]
+[New Thread 0x7ffdcdbff700 (LWP 6515)]
+qemu-system-x86_64: warning: guest updated active QH
+[Switching to Thread 0x7fffee9ff700 (LWP 6340)]
+
+Thread 5 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0)
+    at audio/audio_template.h:304
+304	in audio/audio_template.h
+(gdb) print (*dev)->driver
+$3 = 176
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1836136 b/results/classifier/zero-shot/118/peripherals/1836136
new file mode 100644
index 00000000..9d9d33c5
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1836136
@@ -0,0 +1,42 @@
+peripherals: 0.872
+boot: 0.751
+device: 0.646
+mistranslation: 0.628
+graphic: 0.590
+semantic: 0.424
+ppc: 0.392
+socket: 0.293
+risc-v: 0.273
+register: 0.222
+files: 0.201
+PID: 0.153
+architecture: 0.142
+user-level: 0.139
+permissions: 0.112
+virtual: 0.100
+network: 0.099
+debug: 0.091
+vnc: 0.082
+arm: 0.081
+assembly: 0.056
+performance: 0.055
+VMM: 0.045
+kernel: 0.043
+x86: 0.034
+i386: 0.026
+TCG: 0.025
+hypervisor: 0.013
+KVM: 0.010
+
+u-boot: any plans to update u-boot to v2019.07
+
+Just want to pulse about the plan to update u-boot binary to latest v2019.07.
+
+Are there any notable bugfixes or new features that this would get us for the two platforms where we ship a u-boot binary ?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+As it happens, in April 2021 commit 335b6389374a53e0 bumped our u-boot rom to v2021.04 to fix a PCI issue.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1842925 b/results/classifier/zero-shot/118/peripherals/1842925
new file mode 100644
index 00000000..d3429bc3
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1842925
@@ -0,0 +1,152 @@
+peripherals: 0.920
+user-level: 0.900
+debug: 0.898
+semantic: 0.893
+hypervisor: 0.893
+mistranslation: 0.891
+arm: 0.890
+architecture: 0.886
+graphic: 0.886
+permissions: 0.884
+assembly: 0.882
+register: 0.880
+vnc: 0.868
+device: 0.862
+PID: 0.853
+virtual: 0.839
+risc-v: 0.832
+boot: 0.826
+files: 0.826
+performance: 0.816
+kernel: 0.804
+socket: 0.797
+KVM: 0.764
+ppc: 0.763
+TCG: 0.739
+x86: 0.723
+VMM: 0.670
+network: 0.575
+i386: 0.500
+
+no batmap on convertion from qcow2 to vhd
+
+we run following version of qemu-img:
+$ qemu-img --version
+qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.41), Copyright (c) 2004-2008 Fabrice Bellard
+$
+
+Here is os version:
+$ cat /etc/os-release 
+NAME="Ubuntu"
+VERSION="16.04.6 LTS (Xenial Xerus)"
+ID=ubuntu
+ID_LIKE=debian
+PRETTY_NAME="Ubuntu 16.04.6 LTS"
+VERSION_ID="16.04"
+HOME_URL="http://www.ubuntu.com/"
+SUPPORT_URL="http://help.ubuntu.com/"
+BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
+VERSION_CODENAME=xenial
+UBUNTU_CODENAME=xenial
+$
+
+When we use qemu-img for conversion of qcow2 to vhd newly created file doesnt show batmap summary when we run:
+
+# vhd-util read -p -n centos76.vhd
+VHD Footer Summary:
+-------------------
+Cookie              : conectix
+Features            : (0x00000002) <RESV>
+File format version : Major: 1, Minor: 0
+Data offset         : 512
+Timestamp           : Mon Mar  4 13:21:27 2019
+Creator Application : 'qemu'
+Creator version     : Major: 5, Minor: 3
+Creator OS          : Windows
+Original disk size  : 8192 MB (8590417920 Bytes)
+Current disk size   : 8192 MB (8590417920 Bytes)
+Geometry            : Cyl: 16645, Hds: 16, Sctrs: 63
+                    : = 8192 MB (8590417920 Bytes)
+Disk type           : Dynamic hard disk
+Checksum            : 0xfffff119|0xfffff119 (Good!)
+UUID                : 23772822-a66c-45a2-be37-8474604147c7
+Saved state         : No
+Hidden              : 0
+
+VHD Header Summary:
+-------------------
+Cookie              : cxsparse
+Data offset (unusd) : 18446744073709
+Table offset        : 1536
+Header version      : 0x00010000
+Max BAT size        : 4097
+Block size          : 2097152 (2 MB)
+Parent name         : 
+Parent UUID         : 00000000-0000-0000-0000-000000000000
+Parent timestamp    : Fri Dec 31 19:00:00 1999
+Checksum            : 0xfffff466|0xfffff466 (Good!)
+
+#
+
+I am not so strong in VHD format details and not exactly sure how batmap is needed, but when I do conversion of qcow2 image by using vhd-util at the end I get file with proper batmap summary.
+
+In our environment we use CloudStack and Citrix and we use those converted from qcow2 to vhd images as templates. In general there is no problems, but whenever we create snapshot out of VM created from such template vhd-util read command starts giving us error like below:
+
+#
+-------------------
+Cookie              : conectix
+Features            : (0x00000002) <RESV>
+File format version : Major: 1, Minor: 0
+Data offset         : 512
+Timestamp           : Thu Aug 29 16:04:30 2019
+Creator Application : 'tap'
+Creator version     : Major: 1, Minor: 3
+Creator OS          : Unknown!
+Original disk size  : 8194 MB (8592031744 Bytes)
+Current disk size   : 8194 MB (8592031744 Bytes)
+Geometry            : Cyl: 16648, Hds: 16, Sctrs: 63
+                    : = 8193 MB (8591966208 Bytes)
+Disk type           : Dynamic hard disk
+Checksum            : 0xfffff074|0xfffff074 (Good!)
+UUID                : 2b3cac7d-16e1-4771-b8cd-bb8c7876c761
+Saved state         : No
+Hidden              : 0
+
+VHD Header Summary:
+-------------------
+Cookie              : cxsparse
+Data offset (unusd) : 18446744073709
+Table offset        : 1536
+Header version      : 0x00010000
+Max BAT size        : 4097
+Block size          : 2097152 (2 MB)
+Parent name         : 
+Parent UUID         : 00000000-0000-0000-0000-000000000000
+Parent timestamp    : Sat Jan  1 00:00:00 2000
+Checksum            : 0xfffff466|0xfffff466 (Good!)
+
+failed to get batmap header 
+
+#
+
+With the templates that show correct batmap summary that are created by conversion of qcow2 image by vhd-util convert we don't have such problems.
+
+So I wanted to check with community if not existence of the batmap can cause (be the reason of) this behaviour later on snapshot creation stage? Should we always have batmap summary on output of vhd-util read command?
+
+we use vhd-util from link http://download.cloud.com.s3.amazonaws.com/tools/vhd-util
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1843852 b/results/classifier/zero-shot/118/peripherals/1843852
new file mode 100644
index 00000000..4642e4f3
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1843852
@@ -0,0 +1,106 @@
+peripherals: 0.862
+mistranslation: 0.851
+register: 0.846
+hypervisor: 0.815
+device: 0.810
+socket: 0.809
+graphic: 0.790
+debug: 0.790
+semantic: 0.780
+arm: 0.778
+architecture: 0.774
+risc-v: 0.771
+permissions: 0.768
+assembly: 0.747
+user-level: 0.745
+KVM: 0.732
+ppc: 0.729
+vnc: 0.717
+boot: 0.716
+PID: 0.704
+files: 0.698
+performance: 0.696
+kernel: 0.693
+network: 0.691
+TCG: 0.689
+virtual: 0.631
+VMM: 0.619
+x86: 0.591
+i386: 0.537
+
+QEMU does not express a dependency on perl-Test-Harness
+
+This is a minor thing; in Fedora you can install most of the developer dependencies by issuing something like `dnf builddep qemu-kvm` and this takes care of just about everything such that you can run ./configure and make.
+
+For "make check" though, configure doesn't catch that you'll need perl-Test-Harness; so it fails halfway through the check routine, and you'll see this:
+
+```
+Can't locate TAP/Parser.pm in @INC (you may need to install the TAP::Parser module) (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ./scripts/tap-driver.pl line 30.
+BEGIN failed--compilation aborted at ./scripts/tap-driver.pl line 30.
+make: *** [/home/jhuston/src/qemu/tests/Makefile.include:905: check-unit] Error 2
+```
+
+I'm not sure how we should express this dependency; it shouldn't be a requirement for building, but it IS a dependency for testing. We probably ought not let users skip the qapi tests just because they don't have the perl requirement met.
+
+(And, separately, the Fedora package should list this as a builddep, but that's not an issue for here.)
+
+Given we require python perhaps the simplest solution would be to re-write the tap-driver as a python script rather than adding another configure check?
+
+
+
+On 9/13/19 4:33 AM, Alex Bennée wrote:
+> Given we require python perhaps the simplest solution would be to re-
+> write the tap-driver as a python script rather than adding another
+> configure check?
+> 
+
+Seems a shame to need to after Paolo *just* introduced this perl script
+late last year in 9df43317b82; it looks well-written as far as perl goes.
+
+I think in this case it's less work to just express the dependency.
+
+
+
+
+On 9/13/19 11:06 AM, Paolo Bonzini wrote:
+> On 13/09/19 16:56, John Snow wrote:
+>>
+>>
+>> On 9/13/19 4:33 AM, Alex Bennée wrote:
+>>> Given we require python perhaps the simplest solution would be to re-
+>>> write the tap-driver as a python script rather than adding another
+>>> configure check?
+>>
+>> Seems a shame to need to after Paolo *just* introduced this perl script
+>> late last year in 9df43317b82; it looks well-written as far as perl goes.
+> 
+> Also because I didn't write it most of it (rather, it comes from
+> Automake).  The new dependency was even documented in the release notes:
+> 
+>   Running the QEMU testsuite now requires the Perl Test::Harness module.
+>   Most Linux and BSD distributions however install it by default
+>   together with Perl.
+> 
+
+Yeah, let's just add a warning(?) to the configure check that you'll be
+unable to run `make check` if you're missing this dependency. Easier
+than re-writing.
+
+--js
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1851 b/results/classifier/zero-shot/118/peripherals/1851
new file mode 100644
index 00000000..3689f538
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1851
@@ -0,0 +1,465 @@
+peripherals: 0.833
+architecture: 0.796
+device: 0.793
+hypervisor: 0.790
+user-level: 0.783
+arm: 0.776
+graphic: 0.755
+TCG: 0.750
+permissions: 0.744
+performance: 0.744
+virtual: 0.721
+assembly: 0.719
+register: 0.710
+ppc: 0.707
+socket: 0.662
+risc-v: 0.648
+network: 0.648
+VMM: 0.647
+files: 0.629
+PID: 0.619
+KVM: 0.614
+vnc: 0.598
+debug: 0.595
+kernel: 0.586
+boot: 0.578
+x86: 0.552
+semantic: 0.545
+i386: 0.441
+mistranslation: 0.273
+
+hw/net/rocker: NULL pointer dereference in of_dpa_cmd_add_l2_flood
+Description of problem:
+rocker_tlv_parse_nested could return early because of no group ids in the group_tlvs. In such case tlvs is NULL; tlvs\[i + 1\] in the next for-loop will deref the NULL pointer.
+Steps to reproduce:
+Compile and run the following code within the guest:
+
+```
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <assert.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <sys/mman.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+#include <sys/io.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <err.h>
+#include <errno.h>
+#include <pthread.h>
+
+/*
+ * Rocker DMA ring register offsets
+ */
+#define ROCKER_DMA_DESC_BASE            0x1000
+#define ROCKER_DMA_DESC_SIZE            32
+#define ROCKER_DMA_DESC_MASK            0x1F
+#define ROCKER_DMA_DESC_TOTAL_SIZE \
+    (ROCKER_DMA_DESC_SIZE * 64) /* 62 ports + event + cmd */
+#define ROCKER_DMA_DESC_ADDR_OFFSET     0x00     /* 8-byte */
+#define ROCKER_DMA_DESC_SIZE_OFFSET     0x08
+#define ROCKER_DMA_DESC_HEAD_OFFSET     0x0c
+#define ROCKER_DMA_DESC_TAIL_OFFSET     0x10
+#define ROCKER_DMA_DESC_CTRL_OFFSET     0x14
+#define ROCKER_DMA_DESC_CREDITS_OFFSET  0x18
+#define ROCKER_DMA_DESC_RSVD_OFFSET     0x1c
+
+/*
+ * Rocker dma ctrl register bits
+ */
+#define ROCKER_DMA_DESC_CTRL_RESET      (1 << 0)
+
+/*
+ * Rocker test registers
+ */
+#define ROCKER_TEST_REG                 0x0010
+#define ROCKER_TEST_REG64               0x0018  /* 8-byte */
+#define ROCKER_TEST_IRQ                 0x0020
+#define ROCKER_TEST_DMA_ADDR            0x0028  /* 8-byte */
+#define ROCKER_TEST_DMA_SIZE            0x0030
+#define ROCKER_TEST_DMA_CTRL            0x0034
+
+/*
+ * Rocker general purpose registers
+ */
+#define ROCKER_CONTROL                  0x0300
+#define ROCKER_PORT_PHYS_COUNT          0x0304
+#define ROCKER_PORT_PHYS_LINK_STATUS    0x0310 /* 8-byte */
+#define ROCKER_PORT_PHYS_ENABLE         0x0318 /* 8-byte */
+#define ROCKER_SWITCH_ID                0x0320 /* 8-byte */
+
+/*
+ * Rocker test register ctrl
+ */
+#define ROCKER_TEST_DMA_CTRL_CLEAR      (1 << 0)
+#define ROCKER_TEST_DMA_CTRL_FILL       (1 << 1)
+#define ROCKER_TEST_DMA_CTRL_INVERT     (1 << 2)
+
+#define __le16 uint16_t
+#define __le32 uint32_t
+#define __le64 uint64_t
+
+typedef struct rocker_desc {
+    __le64 buf_addr;
+    uint64_t cookie;
+    __le16 buf_size;
+    __le16 tlv_size;
+    __le16 rsvd[5];   /* pad to 32 bytes */
+    __le16 comp_err;
+} __attribute__((packed, aligned(8))) RockerDesc;
+
+
+/*
+ * Rocker TLV type fields
+ */
+
+typedef struct rocker_tlv {
+    __le32 type;
+    __le16 len;
+    __le16 rsvd;
+} __attribute__((packed, aligned(8))) RockerTlv;
+
+
+typedef struct cmd_group_msg {
+    RockerTlv tlv1;
+    __le64 t1_value;
+    RockerTlv tlv2;
+    __le64 t2_value;
+    RockerTlv tlv3;
+    __le64 t3_value;
+} __attribute__((packed, aligned(8))) CmdGroupMsg;
+
+
+typedef struct cmd_msg {
+    RockerTlv tlv1;
+    __le64 t1_value;
+    RockerTlv tlv2;
+    CmdGroupMsg group_msg;
+} __attribute__((packed, aligned(8))) CmdMsg;
+
+
+typedef struct rx_msg {
+    RockerTlv tlv1;
+    __le64 t1_value;
+    RockerTlv tlv2;
+    __le64 t2_value;
+    RockerTlv tlv3;
+    __le64 t3_value;
+    RockerTlv tlv4;
+    __le64 t4_value;
+    RockerTlv tlv5;
+    __le64 t5_value;
+} __attribute__((packed, aligned(8))) RxMsg;
+
+
+/* Rx msg */
+enum {
+    ROCKER_TLV_RX_UNSPEC,
+    ROCKER_TLV_RX_FLAGS,                /* u16, see RX_FLAGS_ */
+    ROCKER_TLV_RX_CSUM,                 /* u16 */
+    ROCKER_TLV_RX_FRAG_ADDR,            /* u64 */
+    ROCKER_TLV_RX_FRAG_MAX_LEN,         /* u16 */
+    ROCKER_TLV_RX_FRAG_LEN,             /* u16 */
+
+    __ROCKER_TLV_RX_MAX,
+    ROCKER_TLV_RX_MAX = __ROCKER_TLV_RX_MAX - 1,
+};
+
+/* Tx msg */
+enum {
+    ROCKER_TLV_TX_UNSPEC,
+    ROCKER_TLV_TX_OFFLOAD,              /* u8, see TX_OFFLOAD_ */
+    ROCKER_TLV_TX_L3_CSUM_OFF,          /* u16 */
+    ROCKER_TLV_TX_TSO_MSS,              /* u16 */
+    ROCKER_TLV_TX_TSO_HDR_LEN,          /* u16 */
+    ROCKER_TLV_TX_FRAGS,                /* array */
+
+    __ROCKER_TLV_TX_MAX,
+    ROCKER_TLV_TX_MAX = __ROCKER_TLV_TX_MAX - 1,
+};
+
+/* cmd msg */
+enum {
+    ROCKER_TLV_CMD_UNSPEC,
+    ROCKER_TLV_CMD_TYPE,                /* u16 */
+    ROCKER_TLV_CMD_INFO,                /* nest */
+
+    __ROCKER_TLV_CMD_MAX,
+    ROCKER_TLV_CMD_MAX = __ROCKER_TLV_CMD_MAX - 1,
+};
+
+enum {
+    ROCKER_TLV_CMD_TYPE_UNSPEC,
+    ROCKER_TLV_CMD_TYPE_GET_PORT_SETTINGS,
+    ROCKER_TLV_CMD_TYPE_SET_PORT_SETTINGS,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_ADD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_MOD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_DEL,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_FLOW_GET_STATS,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_ADD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_MOD,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_DEL,
+    ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_GET_STATS,
+
+    __ROCKER_TLV_CMD_TYPE_MAX,
+    ROCKER_TLV_CMD_TYPE_MAX = __ROCKER_TLV_CMD_TYPE_MAX - 1,
+};
+
+/*
+ * cmd info nested for OF-DPA msgs
+ */
+
+enum {
+    ROCKER_TLV_OF_DPA_UNSPEC,
+    ROCKER_TLV_OF_DPA_TABLE_ID,            /* u16 */
+    ROCKER_TLV_OF_DPA_PRIORITY,            /* u32 */
+    ROCKER_TLV_OF_DPA_HARDTIME,            /* u32 */
+    ROCKER_TLV_OF_DPA_IDLETIME,            /* u32 */
+    ROCKER_TLV_OF_DPA_COOKIE,              /* u64 */
+    ROCKER_TLV_OF_DPA_IN_PPORT,            /* u32 */
+    ROCKER_TLV_OF_DPA_IN_PPORT_MASK,       /* u32 */
+    ROCKER_TLV_OF_DPA_OUT_PPORT,           /* u32 */
+    ROCKER_TLV_OF_DPA_GOTO_TABLE_ID,       /* u16 */
+    ROCKER_TLV_OF_DPA_GROUP_ID,            /* u32 */
+    ROCKER_TLV_OF_DPA_GROUP_ID_LOWER,      /* u32 */
+    ROCKER_TLV_OF_DPA_GROUP_COUNT,         /* u16 */
+    ROCKER_TLV_OF_DPA_GROUP_IDS,           /* u32 array */
+    ROCKER_TLV_OF_DPA_VLAN_ID,             /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_ID_MASK,        /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_PCP,            /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_PCP_MASK,       /* __be16 */
+    ROCKER_TLV_OF_DPA_VLAN_PCP_ACTION,     /* u8 */
+    ROCKER_TLV_OF_DPA_NEW_VLAN_ID,         /* __be16 */
+    ROCKER_TLV_OF_DPA_NEW_VLAN_PCP,        /* u8 */
+    ROCKER_TLV_OF_DPA_TUNNEL_ID,           /* u32 */
+    ROCKER_TLV_OF_DPA_TUNNEL_LPORT,        /* u32 */
+    ROCKER_TLV_OF_DPA_ETHERTYPE,           /* __be16 */
+    ROCKER_TLV_OF_DPA_DST_MAC,             /* binary */
+    ROCKER_TLV_OF_DPA_DST_MAC_MASK,        /* binary */
+    ROCKER_TLV_OF_DPA_SRC_MAC,             /* binary */
+    ROCKER_TLV_OF_DPA_SRC_MAC_MASK,        /* binary */
+    ROCKER_TLV_OF_DPA_IP_PROTO,            /* u8 */
+    ROCKER_TLV_OF_DPA_IP_PROTO_MASK,       /* u8 */
+    ROCKER_TLV_OF_DPA_IP_DSCP,             /* u8 */
+    ROCKER_TLV_OF_DPA_IP_DSCP_MASK,        /* u8 */
+    ROCKER_TLV_OF_DPA_IP_DSCP_ACTION,      /* u8 */
+    ROCKER_TLV_OF_DPA_NEW_IP_DSCP,         /* u8 */
+    ROCKER_TLV_OF_DPA_IP_ECN,              /* u8 */
+    ROCKER_TLV_OF_DPA_IP_ECN_MASK,         /* u8 */
+    ROCKER_TLV_OF_DPA_DST_IP,              /* __be32 */
+    ROCKER_TLV_OF_DPA_DST_IP_MASK,         /* __be32 */
+    ROCKER_TLV_OF_DPA_SRC_IP,              /* __be32 */
+    ROCKER_TLV_OF_DPA_SRC_IP_MASK,         /* __be32 */
+    ROCKER_TLV_OF_DPA_DST_IPV6,            /* binary */
+    ROCKER_TLV_OF_DPA_DST_IPV6_MASK,       /* binary */
+    ROCKER_TLV_OF_DPA_SRC_IPV6,            /* binary */
+    ROCKER_TLV_OF_DPA_SRC_IPV6_MASK,       /* binary */
+    ROCKER_TLV_OF_DPA_SRC_ARP_IP,          /* __be32 */
+    ROCKER_TLV_OF_DPA_SRC_ARP_IP_MASK,     /* __be32 */
+    ROCKER_TLV_OF_DPA_L4_DST_PORT,         /* __be16 */
+    ROCKER_TLV_OF_DPA_L4_DST_PORT_MASK,    /* __be16 */
+    ROCKER_TLV_OF_DPA_L4_SRC_PORT,         /* __be16 */
+    ROCKER_TLV_OF_DPA_L4_SRC_PORT_MASK,    /* __be16 */
+    ROCKER_TLV_OF_DPA_ICMP_TYPE,           /* u8 */
+    ROCKER_TLV_OF_DPA_ICMP_TYPE_MASK,      /* u8 */
+    ROCKER_TLV_OF_DPA_ICMP_CODE,           /* u8 */
+    ROCKER_TLV_OF_DPA_ICMP_CODE_MASK,      /* u8 */
+    ROCKER_TLV_OF_DPA_IPV6_LABEL,          /* __be32 */
+    ROCKER_TLV_OF_DPA_IPV6_LABEL_MASK,     /* __be32 */
+    ROCKER_TLV_OF_DPA_QUEUE_ID_ACTION,     /* u8 */
+    ROCKER_TLV_OF_DPA_NEW_QUEUE_ID,        /* u8 */
+    ROCKER_TLV_OF_DPA_CLEAR_ACTIONS,       /* u32 */
+    ROCKER_TLV_OF_DPA_POP_VLAN,            /* u8 */
+    ROCKER_TLV_OF_DPA_TTL_CHECK,           /* u8 */
+    ROCKER_TLV_OF_DPA_COPY_CPU_ACTION,     /* u8 */
+
+    __ROCKER_TLV_OF_DPA_MAX,
+    ROCKER_TLV_OF_DPA_MAX = __ROCKER_TLV_OF_DPA_MAX - 1,
+};
+
+#define PAGE_SHIFT  12
+#define PAGE_SIZE   (1 << PAGE_SHIFT)
+#define PFN_PRESENT (1ull << 63)
+#define PFN_PFN     ((1ull << 55) - 1)
+
+uint64_t get_physical_pfn(void* ptr)
+{
+    uint64_t pfn = -1;
+    FILE* fp = fopen("/proc/self/pagemap", "rb");
+    if (!fp)
+    {
+        return pfn;
+    }
+
+    if (!fseek(fp, (unsigned long)ptr / PAGE_SIZE * 8, SEEK_SET))
+    {
+        fread(&pfn, sizeof(pfn), 1, fp);
+        if (pfn & PFN_PRESENT)
+        {
+            pfn &= PFN_PFN;
+        }
+    }
+    fclose(fp);
+    return pfn;
+}
+
+uint64_t get_physical_addr(void* ptr)
+{
+    uint64_t pfn = get_physical_pfn(ptr);
+    return pfn * PAGE_SIZE + (uint64_t)ptr % PAGE_SIZE;
+}
+
+void* mmio_mem;
+
+void mmio_write(uint32_t addr, uint32_t value)
+{
+    *((uint32_t*)(mmio_mem + addr))= value;
+}
+
+void mmio_write64(uint32_t addr, uint64_t value)
+{
+    *((uint64_t*)(mmio_mem + addr))= value;
+}
+
+uint64_t mmio_read(uint32_t addr)
+{
+    return *((uint64_t*)(mmio_mem +addr));
+}
+
+uint64_t mmio_read64(uint64_t addr)
+{
+    return *((uint64_t*)(mmio_mem +addr));
+}
+
+uint64_t ring_desk_base_addr(int index)
+{
+    return ROCKER_DMA_DESC_BASE + index * 32;
+}
+
+int main()
+{
+    int mmio_fd= open("/sys/devices/pci0000:00/0000:00:04.0/resource0", O_RDWR | O_SYNC);
+    if (mmio_fd== -1) {
+        printf("mmio_fd open failed");
+    	return 1;
+    }
+
+    mmio_mem = mmap(0, 0x2000, PROT_READ | PROT_WRITE, MAP_SHARED, mmio_fd, 0);
+    if (mmio_mem == MAP_FAILED) {
+        printf("mmap mmio_mem failed");
+	return 1;
+    }
+
+    iopl(3);
+
+    RockerTlv cmd_group_tlv = {ROCKER_TLV_OF_DPA_GROUP_ID, sizeof(RockerTlv) + sizeof(__le64), 12345 };
+    RockerTlv cmd_count_tlv = {ROCKER_TLV_OF_DPA_GROUP_COUNT, sizeof(RockerTlv) + sizeof(__le64), 12345};
+    RockerTlv cmd_ids_tlv = {ROCKER_TLV_OF_DPA_GROUP_IDS, sizeof(RockerTlv) + sizeof(__le64), 12345 };
+
+    CmdGroupMsg group_msg = { cmd_group_tlv, 0x40000000, cmd_count_tlv, 65535, cmd_ids_tlv, 12345};
+
+    RockerTlv cmd_type_tlv = {ROCKER_TLV_CMD_TYPE, sizeof(RockerTlv) + sizeof(__le64), 12345 };
+    RockerTlv cmd_info_tlv = {ROCKER_TLV_CMD_INFO, sizeof(RockerTlv) + sizeof(CmdGroupMsg), 12345 };
+    CmdMsg cmd_msg = {cmd_type_tlv, ROCKER_TLV_CMD_TYPE_OF_DPA_GROUP_ADD, cmd_info_tlv, group_msg };
+    RockerDesc cmd_desc = {get_physical_addr(&cmd_msg), 0xdeadbeef, sizeof(CmdMsg), sizeof(CmdMsg), 0x1, 0x4242 };
+
+    mmio_write64(ROCKER_PORT_PHYS_ENABLE, 0xE);
+
+    // cmd ring
+    mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_CTRL_OFFSET, ROCKER_DMA_DESC_CTRL_RESET);
+    // base_addr
+    mmio_write64(ring_desk_base_addr(0), get_physical_addr(&cmd_desc));
+    mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_SIZE_OFFSET, 8);
+    mmio_write(ring_desk_base_addr(0) + ROCKER_DMA_DESC_HEAD_OFFSET, 4);
+
+    printf("End\n");
+    return 0;
+}
+```
+
+Stack trace:
+
+```plaintext
+===================================================================================================
+ldl_he_p(const void * ptr) (/home/arayz/arayz/qemu-git-e1000e/include/qemu/bswap.h:359)
+ldl_le_p(const void * ptr) (/home/arayz/arayz/qemu-git-e1000e/include/qemu/bswap.h:394)
+rocker_tlv_get_le32(const RockerTlv * tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_tlv.h:114)
+of_dpa_cmd_add_l2_flood(OfDpa * of_dpa, OfDpaGroup * group, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2043)
+of_dpa_cmd_group_do(OfDpa * of_dpa, uint32_t group_id, OfDpaGroup * group, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2125)
+of_dpa_cmd_group_add(OfDpa * of_dpa, uint32_t group_id, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2145)
+of_dpa_group_cmd(OfDpa * of_dpa, struct desc_info * info, char * buf, uint16_t cmd, RockerTlv ** group_tlvs) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2204)
+of_dpa_cmd(World * world, struct desc_info * info, char * buf, uint16_t cmd, RockerTlv * cmd_info_tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_of_dpa.c:2234)
+world_do_cmd(World * world, DescInfo * info, char * buf, uint16_t cmd, RockerTlv * cmd_info_tlv) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_world.c:43)
+cmd_consume(Rocker * r, DescInfo * info) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:450)
+ring_pump(DescRing * ring) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_desc.c:242)
+desc_ring_set_head(DescRing * ring, uint32_t new) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker_desc.c:281)
+rocker_io_writel(void * opaque, hwaddr addr, uint32_t val) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:805)
+rocker_mmio_write(void * opaque, hwaddr addr, uint64_t val, unsigned int size) (/home/arayz/arayz/qemu-git-e1000e/hw/net/rocker/rocker.c:996)
+memory_region_write_accessor(MemoryRegion * mr, hwaddr addr, uint64_t * value, unsigned int size, int shift, uint64_t mask, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:492)
+access_with_adjusted_size(hwaddr addr, uint64_t * value, unsigned int size, unsigned int access_size_min, unsigned int access_size_max, MemTxResult (*)(MemoryRegion *, hwaddr, uint64_t *, unsigned int, int, uint64_t, MemTxAttrs) access_fn, MemoryRegion * mr, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:554)
+memory_region_dispatch_write(MemoryRegion * mr, hwaddr addr, uint64_t data, MemOp op, MemTxAttrs attrs) (/home/arayz/arayz/qemu-git-e1000e/softmmu/memory.c:1514)
+flatview_write_continue(FlatView * fv, hwaddr addr, MemTxAttrs attrs, const void * ptr, hwaddr len, hwaddr addr1, hwaddr l, MemoryRegion * mr) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2783)
+flatview_write(FlatView * fv, hwaddr addr, MemTxAttrs attrs, const void * buf, hwaddr len) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2823)
+address_space_write(AddressSpace * as, hwaddr addr, MemTxAttrs attrs, const void * buf, hwaddr len) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2915)
+address_space_rw(AddressSpace * as, hwaddr addr, MemTxAttrs attrs, void * buf, hwaddr len, _Bool is_write) (/home/arayz/arayz/qemu-git-e1000e/softmmu/physmem.c:2925)
+kvm_cpu_exec(CPUState * cpu) (/home/arayz/arayz/qemu-git-e1000e/accel/kvm/kvm-all.c:2929)
+kvm_vcpu_thread_fn(void * arg) (/home/arayz/arayz/qemu-git-e1000e/accel/kvm/kvm-accel-ops.c:49)
+qemu_thread_start(void * args) (/home/arayz/arayz/qemu-git-e1000e/util/qemu-thread-posix.c:556)
+libpthread.so.0!start_thread(void * arg) (/build/glibc-sMfBJT/glibc-2.31/nptl/pthread_create.c:477)
+libc.so.6!clone() (/build/glibc-sMfBJT/glibc-2.31/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
+===================================================================================================
+
+    disassemble and register context:
+===================================================================================================
+Dump of assembler code for function ldl_he_p:
+   0x000055d8a1a473e6 <+0>:	push   %rbp
+   0x000055d8a1a473e7 <+1>:	mov    %rsp,%rbp
+   0x000055d8a1a473ea <+4>:	sub    $0x20,%rsp
+   0x000055d8a1a473ee <+8>:	mov    %rdi,-0x18(%rbp)
+   0x000055d8a1a473f2 <+12>:	mov    %fs:0x28,%rax
+   0x000055d8a1a473fb <+21>:	mov    %rax,-0x8(%rbp)
+   0x000055d8a1a473ff <+25>:	xor    %eax,%eax
+   0x000055d8a1a47401 <+27>:	mov    -0x18(%rbp),%rax
+=> 0x000055d8a1a47405 <+31>:	mov    (%rax),%eax
+   0x000055d8a1a47407 <+33>:	mov    %eax,-0xc(%rbp)
+   0x000055d8a1a4740a <+36>:	mov    -0xc(%rbp),%eax
+   0x000055d8a1a4740d <+39>:	mov    -0x8(%rbp),%rdx
+   0x000055d8a1a47411 <+43>:	xor    %fs:0x28,%rdx
+   0x000055d8a1a4741a <+52>:	je     0x55d8a1a47421 <ldl_he_p+59>
+   0x000055d8a1a4741c <+54>:	callq  0x55d8a186d6d0 <__stack_chk_fail@plt>
+   0x000055d8a1a47421 <+59>:	leaveq 
+   0x000055d8a1a47422 <+60>:	retq   
+End of assembler dump.
+
+rax            0x8                 8
+rbx            0x7f7828088ac0      140154044451520
+rcx            0x0                 0
+rdx            0x7f7828088ac0      140154044451520
+rsi            0x8                 8
+rdi            0x8                 8
+rbp            0x7f7832cfd100      0x7f7832cfd100
+rsp            0x7f7832cfd0e0      0x7f7832cfd0e0
+r8             0x7f7828088ac0      140154044451520
+r9             0x7f7828000790      140154043893648
+r10            0x7f78280008d0      140154043893968
+r11            0x7f7828000080      140154043891840
+r12            0x7ffec007cb1e      140732120156958
+r13            0x7ffec007cb1f      140732120156959
+r14            0x7ffec007cbe0      140732120157152
+r15            0x7f7832cfdb00      140154225285888
+rip            0x55d8a1a47405      0x55d8a1a47405 <ldl_he_p+31>
+eflags         0x10246             [ PF ZF IF RF ]
+cs             0x33                51
+ss             0x2b                43
+ds             0x0                 0
+es             0x0                 0
+fs             0x0                 0
+gs             0x0                 0
+===================================================================================================
+```
+Additional information:
+This was wrongly assigned a high-severity CVE and is being discussed on qemu-devel ML: https://lists.nongnu.org/archive/html/qemu-devel/2023-08/msg04621.html
diff --git a/results/classifier/zero-shot/118/peripherals/1851095 b/results/classifier/zero-shot/118/peripherals/1851095
new file mode 100644
index 00000000..175216b5
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1851095
@@ -0,0 +1,102 @@
+peripherals: 0.945
+debug: 0.926
+semantic: 0.924
+graphic: 0.904
+performance: 0.900
+device: 0.892
+architecture: 0.889
+arm: 0.871
+assembly: 0.863
+PID: 0.837
+permissions: 0.832
+register: 0.829
+risc-v: 0.811
+hypervisor: 0.802
+socket: 0.799
+vnc: 0.799
+files: 0.785
+network: 0.764
+boot: 0.751
+user-level: 0.746
+ppc: 0.733
+mistranslation: 0.690
+VMM: 0.657
+kernel: 0.649
+TCG: 0.629
+virtual: 0.579
+x86: 0.525
+KVM: 0.493
+i386: 0.361
+
+[feature request] awareness of instructions that are well emulated
+
+While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64). Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed.
+
+Here is a pull request for the zig language that runs into this problems in qemu https://github.com/ziglang/zig/pull/2945/
+
+I have more code for validation if someone is working on this.
+
+On Sun, 3 Nov 2019 at 04:41, Shawn Landden <email address hidden> wrote:
+> While qemu's scalar emulation tends to be excellent, qemu's SIMD
+> emulation tends to be incorrect (except for arm64 from x86_64)--i have
+> found this both for mipsel and arm32. Until these code paths are
+> audited, which is probably a large job, it would be nice if qemu knew
+> its emulation of this class of instructions was not very good, and thus
+> it would give up on finding these instructions if a "careful" operation
+> is passed.
+
+I'm not sure how this could work. If QEMU reports (via ID regs
+etc) to the guest that it supports instruction class X when it
+does not, that's a bug and we should fix it. If QEMU implements
+an instruction but gets it wrong, that's also a bug and we should
+fix it. In both cases, we'd need to have specific bug reports,
+ideally with reproduce-cases. But we don't really have "known
+areas where the emulation is incorrect" that we could somehow
+differentiate and disable (except at a very vague level, eg
+"probably better not to rely on the x86 emulation").
+
+You might be able by careful selection of the cpu type to avoid
+CPUs which implement vector operations. Some architectures
+also allow individual CPU features to be disabled with extra
+'-foo' qualifiers on the -cpu argument.
+
+For Arm in particular (32 or 64 bit) I believe our implementation
+should be correct and am happy to look at bug reports for that.
+
+thanks
+-- PMM
+
+
+ok, here is a double precision exponent implementation that works on arm32 hardware, but fails in qemu with the wrong checksum. https://github.com/shawnl/zig-libmvec/blob/master/exp.zig
+
+You need to build zig with the above patch-set.
+
+I guess I am starting from a pessimistic perspective, where I have only ever seen SIMD work with arm64 emulation (which is quite new), and am sorry for that.
+
+Can you please provide a binary (preferably statically built or with required shared libraries attached)?
+
+Thanks,
+
+Laurent
+
+example binary doing double-precision exponent on 16 megs
+
+expected output:
+
+checksum: f181b401cd42aa7b
+
+actual output:
+
+checksum: 4004022b0ba624fb
+
+
+Here is the same thing compiled with optimizations on
+
+appears the random number generator produces different results on 32-bit arches, while my code seems to work fine in qemu
+
+I can confirm bench_simple gives the same result on both qemu-arm and my aarch32 hardware.
+
+Can you provide a clearer repro example of what doesn't wirk on mipsel platform?
+
+In last two QEMU releases mips (Wave) developers went to great lenghts making sure both mips SIMD and mips FP instructions (in both scalar and vector variants) are emulated properly. Some of the unit tests were published, but also many were left internal, and there are many integration tests devised and run as well. We in mips (Wave) consider these two areas well tested. Still, we'll consider seriuosly fixing your example, if you prove experimentally that this is a mips-related bug, but just provides us with a reasonably convenient repro procedure.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1852196 b/results/classifier/zero-shot/118/peripherals/1852196
new file mode 100644
index 00000000..edbcb8fa
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1852196
@@ -0,0 +1,112 @@
+peripherals: 0.929
+permissions: 0.906
+assembly: 0.893
+arm: 0.893
+semantic: 0.886
+register: 0.869
+user-level: 0.868
+device: 0.864
+graphic: 0.856
+mistranslation: 0.855
+performance: 0.849
+files: 0.846
+PID: 0.839
+socket: 0.837
+architecture: 0.836
+debug: 0.834
+risc-v: 0.824
+kernel: 0.821
+virtual: 0.819
+TCG: 0.781
+ppc: 0.779
+vnc: 0.759
+boot: 0.739
+hypervisor: 0.728
+KVM: 0.723
+VMM: 0.697
+network: 0.689
+x86: 0.450
+i386: 0.128
+
+update edk2 submodule & binaries to edk2-stable202008
+
+edk2-stable201911 will be tagged soon:
+
+  https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
+
+  https://github.com/tianocore/edk2/releases/tag/edk2-stable201911
+  [upcoming link]
+
+It should be picked up by QEMU, after the v4.2.0 release.
+
+Relevant fixes / features in edk2, since edk2-stable201905 (which is
+what QEMU bundles at the moment, from LP#1831477):
+
+- enable UEFI HTTPS Boot in ArmVirtQemu* platforms
+  https://bugzilla.tianocore.org/show_bug.cgi?id=1009
+  (this is from edk2-stable201908)
+
+- fix CVE-2019-14553 (Invalid server certificate accepted in HTTPS Boot)
+  https://bugzilla.tianocore.org/show_bug.cgi?id=960
+
+- consume OpenSSL-1.1.1d, for fixing CVE-2019-1543, CVE-2019-1552 and
+  CVE-2019-1563
+  https://bugzilla.tianocore.org/show_bug.cgi?id=2226
+
+Hi Laszlo,
+
+Do you have a particular reason to update the submodule *after* the v4.2.0 release?
+I'd rather see QEMU 4.2 released with edk2-stable201911, as it fixes various CVE (therefore a patch for 4.2-rc4 seems acceptable to me).
+
+
+Yes, I do have a reason for delaying this LP until after 4.2.0 is out.
+
+When I filed this ticket (on 2019-Nov-12), QEMU had already entered the 4.2.0 soft feature freeze (on 2019-Oct-29). Despite possible appearances, this LP is actually a feature addition -- that's why I also set "Tags: feature-request" when I filed this LP.
+
+The reason this is not a fix but a feature addition is the following:
+- CVE-2019-14553 is irrelevant (doesn't exist) until we enable HTTPS Boot,
+- we have not enabled HTTPS Boot earlier exactly because of CVE-2019-14553,
+- the plan is to enable HTTPS Boot now, with CVE-2019-14553 fixed,
+- so what remains are CVE-2019-1543, CVE-2019-1552 and CVE-2019-1563, which are native OpenSSL problems.
+
+The upstream edk2 project advanced to OpenSSL 1.1.1d because of the last point (i.e. because of those three OpenSSL CVEs). That submodule update was tracked in:
+
+https://bugzilla.tianocore.org/show_bug.cgi?id=2226
+
+As you can see:
+
+(1) there was zero analysis or explanation how those OpenSSL CVEs would *actually* affect edk2 platforms,
+
+(2) edk2 advanced to OpenSSL 1.1.1d (on 2019-Nov-05) approximately two months after upstream OpenSSL 1.1.1d was released (on 2019-Sep-10).
+
+Furthermore,
+
+(3) all the listed CVEs are marked "low severity":
+
+https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1543
+https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1552
+https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1563
+
+(The first two items are declared low severity on cve.mitre.org, while the last item is declared low severity in <https://www.openssl.org/news/secadv/20190910.txt>.)
+
+These points (1) through (3) tell me that the edk2 advance was more or less "better safe than sorry" or "cargo cult".
+
+While that approach is not necessarily wrong, if you have infinite amounts of time, my capacity falls near the other end of the spectrum. If someone runs QEMU in production, they should build their firmware from source anyway -- the bundling of edk2 binaries with QEMU is a convenience.
+
+If you'd like to submit a QEMU patch set (just for the sake of the CVE fixes, not the HTTPS Boot feature), and are willing to make the case for getting that into 4.2-rc4, I won't block it, but I don't think it's worth the churn, to be honest.
+
+Thanks!
+Laszlo
+
+Posted
+
+* [qemu-devel] [PATCH 00/10] edk2: adopt the edk2-stable202008 release
+
+http://<email address hidden>
+
+
+
+Commit a68694cd1f3.
+
+Released with QEMU v5.2.0.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1855535 b/results/classifier/zero-shot/118/peripherals/1855535
new file mode 100644
index 00000000..d619d0f2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1855535
@@ -0,0 +1,88 @@
+peripherals: 0.833
+graphic: 0.769
+PID: 0.765
+boot: 0.761
+ppc: 0.753
+kernel: 0.749
+hypervisor: 0.733
+device: 0.729
+network: 0.727
+vnc: 0.709
+semantic: 0.705
+user-level: 0.701
+risc-v: 0.693
+debug: 0.693
+virtual: 0.691
+arm: 0.662
+i386: 0.660
+socket: 0.657
+architecture: 0.644
+x86: 0.641
+mistranslation: 0.640
+permissions: 0.634
+register: 0.611
+assembly: 0.581
+VMM: 0.575
+TCG: 0.573
+files: 0.543
+performance: 0.489
+KVM: 0.452
+
+Connection reset by peer when using port fwd
+
+$ qemu-system-ppc64 -cpu POWER8,compat=power7 -machine pseries -m 8G -smp cores=8 -serial mon:stdio -nographic \
+-drive file=/qemu/aix72.img,if=none,id=drive-virtio-disk0 \
+-device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
+-cdrom /qemu/aix72.iso \
+-prom-env boot-command='boot disk:' \
+-name ctsprod -k es \
+-netdev user,id=netdev0,hostfwd=tcp:127.0.0.1:2222-:22 \
+-device virtio-net-pci,netdev=netdev0 \
+-netdev bridge,id=hostnet0,br=virbr0 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:96:2f:7a \
+-device virtio-net,netdev=vmnic -netdev tap,id=vmnic,ifname=vnet0,script=no,downscript=no \
+-monitor telnet:127.0.0.1:5801,server,nowait,nodelay
+
+
+$ ssh -p 2222 root@127.0.0.1 -v
+
+OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
+debug1: Reading configuration data /etc/ssh/ssh_config
+debug1: /etc/ssh/ssh_config line 19: Applying options for *
+debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222.
+debug1: Connection established.
+debug1: permanently_set_uid: 0/0
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_rsa type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_rsa-cert type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_dsa type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_dsa-cert type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_ecdsa type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_ecdsa-cert type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_ed25519 type -1
+debug1: key_load_public: No such file or directory
+debug1: identity file /root/.ssh/id_ed25519-cert type -1
+debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
+ssh_exchange_identification: read: Connection reset by peer
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1863 b/results/classifier/zero-shot/118/peripherals/1863
new file mode 100644
index 00000000..8f1b73c5
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1863
@@ -0,0 +1,102 @@
+peripherals: 0.905
+x86: 0.883
+permissions: 0.868
+graphic: 0.845
+vnc: 0.842
+register: 0.839
+user-level: 0.834
+ppc: 0.832
+architecture: 0.830
+TCG: 0.830
+debug: 0.822
+hypervisor: 0.820
+arm: 0.819
+VMM: 0.816
+network: 0.811
+mistranslation: 0.810
+performance: 0.809
+device: 0.809
+files: 0.797
+semantic: 0.794
+KVM: 0.788
+virtual: 0.774
+socket: 0.769
+i386: 0.766
+assembly: 0.766
+PID: 0.765
+risc-v: 0.746
+kernel: 0.703
+boot: 0.631
+
+Assertion `core->delayed_causes == 0` failed in hw/net/e1000e_core.c:353 during fuzzing
+Description of problem:
+Got an assertion failure `core->delayed_causes == 0` when fuzzing e1000e.
+Steps to reproduce:
+Minimized reproducer for the error:
+
+```plaintext
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M q35 \
+-nodefaults -device e1000e,netdev=net0 -netdev user,id=net0 -qtest \
+/dev/null -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80000804
+outw 0xcfc 0x06
+write 0xe000042a 0x2 0x0241
+write 0xe0000402 0x2 0x0200
+write 0x400b 0x1 0x88
+write 0xe0000438 0x4 0x01040000
+outl 0xcf8 0x800008a3
+outb 0xcfc 0x80
+EOF
+```
+Additional information:
+The crash report triggered by the reproducer is:
+
+```plaintext
+qemu-fuzz-x86_64: /../hw/net/e1000e_core.c:353: uint32_t e1000e_intmgr_collect_delayed_causes(E1000ECore *): Assertion `core->delayed_causes == 0' failed.
+==2036033== ERROR: libFuzzer: deadly signal
+    #0 0x5606ff6c555e in __sanitizer_print_stack_trace ../../../llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3
+    #1 0x5606ff607bb1 in fuzzer::PrintStackTrace() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x5606ff5e2486 in fuzzer::Fuzzer::CrashCallback() (.part.0) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18
+    #3 0x5606ff5e254d in fuzzer::Fuzzer::CrashCallback() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1
+    #4 0x5606ff5e254d in fuzzer::Fuzzer::StaticCrashSignalCallback() ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19
+    #5 0x7f7490e4e41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
+    #6 0x7f7490c4200a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f7490c4200a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f7490c21858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f7490c21728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f7490c32fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x5606ffd20c33 in e1000e_intmgr_collect_delayed_causes ../hw/net/e1000e_core.c:353:9
+    #12 0x5606ffd20c33 in e1000e_set_interrupt_cause ../hw/net/e1000e_core.c:2203:12
+    #13 0x5606ffd1bd1b in e1000e_receive_internal ../hw/net/e1000e_core.c:1751:9
+    #14 0x56070055a58a in qemu_deliver_packet_iov ../net/net.c:820:15
+    #15 0x56070055e215 in qemu_net_queue_deliver ../net/queue.c:164:11
+    #16 0x56070055f9ca in qemu_net_queue_flush ../net/queue.c:286:15
+    #17 0x56070054f5c8 in qemu_flush_or_purge_queued_packets ../net/net.c:681:9
+    #18 0x5606ffd14ff5 in e1000e_start_recv ../hw/net/e1000e_core.c:983:9
+    #19 0x5606ffd3c33b in e1000e_set_rx_control ../hw/net/e1000e_core.c:1959:9
+    #20 0x5606ffd20fe8 in e1000e_core_write ../hw/net/e1000e_core.c:3306:9
+    #21 0x560700caeb43 in memory_region_write_accessor ../softmmu/memory.c:493:5
+    #22 0x560700cae2ca in access_with_adjusted_size ../softmmu/memory.c:569:18
+    #23 0x560700cad670 in memory_region_dispatch_write ../softmmu/memory.c
+    #24 0x560700cf7d6f in flatview_write_continue ../softmmu/physmem.c:2677:23
+    #25 0x560700cef213 in flatview_write ../softmmu/physmem.c:2719:12
+    #26 0x560700ceef27 in address_space_write ../softmmu/physmem.c:2815:18
+    #27 0x560700420b2f in qtest_process_command ../softmmu/qtest.c:558:13
+    #28 0x56070041ecfb in qtest_process_inbuf ../softmmu/qtest.c:810:9
+    #29 0x56070041eb19 in qtest_server_inproc_recv ../softmmu/qtest.c:941:9
+    #30 0x56070126a792 in qtest_sendf ../tests/qtest/libqtest.c:607:5
+    #31 0x56070126ae9e in qtest_write ../tests/qtest/libqtest.c:1072:5
+    #32 0x56070126ae9e in qtest_writel ../tests/qtest/libqtest.c:1088:5
+    #33 0x5606ff7058cb in __wrap_qtest_writel ../tests/qtest/fuzz/qtest_wrappers.c:180:9
+    #34 0x5606ff70d5f2 in op_write ../tests/qtest/fuzz/generic_fuzz.c:485:13
+    #35 0x5606ff70bd2f in generic_fuzz ../tests/qtest/fuzz/generic_fuzz.c:666:13
+    #36 0x5606ff7008e7 in LLVMFuzzerTestOneInput ../tests/qtest/fuzz/fuzz.c:158:5
+    #37 0x5606ff5e2d08 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:612:15
+    #38 0x5606ff5c6124 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:21
+    #39 0x5606ff5d2b0a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:19
+    #40 0x5606ff5bd8d6 in main ../../../llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #41 0x7f7490c23082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #42 0x5606ff5bd95d in _start (./qemu-fuzz-x86_64+0x1ef595d)
+```
diff --git a/results/classifier/zero-shot/118/peripherals/1863200 b/results/classifier/zero-shot/118/peripherals/1863200
new file mode 100644
index 00000000..8b471435
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1863200
@@ -0,0 +1,122 @@
+user-level: 0.933
+peripherals: 0.920
+mistranslation: 0.913
+vnc: 0.907
+ppc: 0.901
+KVM: 0.884
+register: 0.875
+risc-v: 0.874
+TCG: 0.869
+hypervisor: 0.865
+x86: 0.861
+virtual: 0.859
+VMM: 0.853
+permissions: 0.851
+performance: 0.847
+network: 0.839
+graphic: 0.834
+debug: 0.831
+architecture: 0.816
+socket: 0.811
+device: 0.805
+semantic: 0.805
+arm: 0.801
+assembly: 0.801
+files: 0.799
+PID: 0.762
+boot: 0.761
+kernel: 0.712
+i386: 0.566
+
+Reconnect failed with loopback virtio1.1 server mode test
+
+Issue discription：
+Packed ring server mode is a new feature to enable the virtio-user or virtio-pmd(in VM) as the server, vhost as the client, then when the vhost-user is killed then re-launched, the vhost-user can connect back to virtio-user/virtio-pmd again. Test with dpdk 20.02 ,virtio-pmd loopback reconnect from vhost-user failed.
+
+Test Environment:
+DPDK version: DPDK v20.02
+Other software versions: virtio1.1
+Qemu versions:4.2.0
+OS: Linux 4.15.0-20-generic
+Compiler: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
+Hardware platform: R2208WFTZSR.
+
+The reproduce step is :
+Test Case: vhost-user/virtio-pmd loopback reconnect from vhost-user
+===============================================================
+Flow: Vhost-user --> Virtio --> Vhost-user
+
+1. Launch vhost-user with client mode by below commands::
+
+    ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1
+    testpmd>set fwd mac
+
+2. Start VM with 1 virtio device, and set the qemu as server mode::
+
+    ./qemu-system-x86_64 -name vm2 -enable-kvm -cpu host -smp 100 -m 8G \
+    -object memory-backend-file,id=mem,size=8192M,mem-path=/mnt/huge,share=on \
+    -numa node,memdev=mem -mem-prealloc -drive file=/home/xuan/dpdk_project/shell/u18.img  \
+    -chardev socket,path=/tmp/vm2_qga0.sock,server,nowait,id=vm2_qga0 -device virtio-serial \
+    -device virtserialport,chardev=vm2_qga0,name=org.qemu.guest_agent.2 -daemonize \
+    -monitor unix:/tmp/vm2_monitor.sock,server,nowait -net nic,macaddr=00:00:00:08:e8:aa,addr=1f \
+    -net user,hostfwd=tcp:127.0.0.1:6002-:22 \
+    -chardev socket,id=char0,path=/tmp/vhost-net,server \
+    -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \
+    -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,mrg_rxbuf=on,rx_queue_size=1024,tx_queue_size=1024,packed=on \
+    -vnc :10
+
+3. On VM, bind virtio net to igb_uio and run testpmd::
+
+    ./testpmd -c 0x3 -n 4 -- -i --nb-cores=1 --txd=1024 --rxd=1024
+    testpmd>set fwd mac
+    testpmd>start
+
+4. Send packets by vhost-user, check if packets can be RX/TX with virtio-pmd::
+
+    testpmd>start tx_first 32
+    testpmd>show port stats all
+
+5. On host, quit vhost-user, then re-launch the vhost-user with below command::
+
+    testpmd>quit
+    ./testpmd -c 0x30 -n 4 --socket-mem 1024,1024 --legacy-mem --vdev 'eth_vhost0,iface=/tmp/vhost-net,client=1,queues=1' -- -i --nb-cores=1
+    testpmd>set fwd mac
+    testpmd>start tx_first 32
+
+6. Check if the reconnection can work, still send packets by vhost-user, check if packets can be RX/TX with virtio-pmd::
+
+    testpmd>show port stats all 
+
+Expected result::
+
+After the vhost-user is killed then re-launched, the VM can connect back to vhost-user again with throughput.
+
+Real result::
+
+After the vhost-user is killed then re-launched, no throughput with PVP.
+
+Analysis::
+
+QEMU has its own way to handle reconnect function for virtio server mode. However, for packed ring, when reconnecting to virtio, vhost cannot get the status of descriptors via the descriptor ring. This bug is caused since the reconnection for packed ring need additional reset operation.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/248
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1866 b/results/classifier/zero-shot/118/peripherals/1866
new file mode 100644
index 00000000..86e5fd10
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1866
@@ -0,0 +1,31 @@
+peripherals: 0.976
+device: 0.930
+network: 0.908
+performance: 0.851
+graphic: 0.685
+arm: 0.651
+TCG: 0.631
+architecture: 0.549
+VMM: 0.529
+vnc: 0.468
+risc-v: 0.462
+boot: 0.372
+ppc: 0.365
+debug: 0.309
+files: 0.257
+virtual: 0.255
+mistranslation: 0.187
+register: 0.185
+semantic: 0.182
+PID: 0.174
+user-level: 0.160
+hypervisor: 0.148
+kernel: 0.116
+socket: 0.116
+permissions: 0.059
+KVM: 0.037
+assembly: 0.006
+x86: 0.006
+i386: 0.005
+
+mips/mip64 virtio broken on master (and 8.1.0 with tcg fix)
diff --git a/results/classifier/zero-shot/118/peripherals/1869858 b/results/classifier/zero-shot/118/peripherals/1869858
new file mode 100644
index 00000000..4cf0f075
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1869858
@@ -0,0 +1,45 @@
+peripherals: 0.942
+graphic: 0.892
+architecture: 0.883
+performance: 0.845
+mistranslation: 0.744
+semantic: 0.686
+device: 0.643
+user-level: 0.643
+arm: 0.559
+ppc: 0.345
+KVM: 0.343
+network: 0.300
+TCG: 0.293
+virtual: 0.290
+files: 0.221
+hypervisor: 0.193
+vnc: 0.186
+boot: 0.170
+register: 0.166
+socket: 0.156
+permissions: 0.147
+assembly: 0.123
+debug: 0.116
+VMM: 0.101
+PID: 0.095
+risc-v: 0.072
+kernel: 0.064
+i386: 0.028
+x86: 0.026
+
+qemu can't start Windows10arm64 19H1(with kvm)
+
+My cpu's model is arm64(cortex-a53),I want start Win10arm64 with kvm,Because is fast than x86.But it's did'nt work.The screnn is card in Uefi's logo. But I am use ramfb now,So it has nothing to do with the graphics card.But if I discard kvm,It can start now.But its so slowly.But I use the uefi and kvm can start with Debian arm64 buster. So who's the problem?qemu or kvm or Microsoft?But others use it to start successfully. I don't know what I would like to do
+This is start command(Qemu version is 4.1')
+qemu-system-aarch64 -hda /win10.vhdx -cdrom /win10arm.iso -m 1G -accel kvm -smp 4 -cpu host -pflash efi.img -pflash var.img -device ramfb -device qemu-xhci -device usb-kbd -device usb-mouse -device usb-tablet
+If I replace the above three parameters with "- CPU cortex-a53" and "- accel TCG" and "- device VGA", I can start normally. What's the matter?
+
+What is your host machine? And could you please try with the latest version of QEMU (v5.0)?
+
+I try use latest qemu，but It was the same
+
+And I am try Windows 10 build 19613，but was cant not start，too(sorry，My english It's not well)
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1874678 b/results/classifier/zero-shot/118/peripherals/1874678
new file mode 100644
index 00000000..afd663db
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1874678
@@ -0,0 +1,87 @@
+peripherals: 0.910
+permissions: 0.757
+device: 0.752
+user-level: 0.744
+hypervisor: 0.739
+graphic: 0.726
+risc-v: 0.715
+PID: 0.709
+virtual: 0.693
+register: 0.693
+semantic: 0.682
+socket: 0.666
+network: 0.640
+performance: 0.635
+boot: 0.634
+assembly: 0.632
+files: 0.615
+VMM: 0.608
+mistranslation: 0.605
+debug: 0.598
+arm: 0.596
+TCG: 0.594
+ppc: 0.569
+architecture: 0.565
+x86: 0.539
+kernel: 0.537
+vnc: 0.497
+KVM: 0.479
+i386: 0.425
+
+[Feature request] python-qemu package
+
+It would be useful to have the python/qemu/ files publish as a Python pip package, so users from distribution can also use the QEMU python methods (in particular for testing) without having to clone the full repository.
+
+Hello, I am new to the community and I would like to cut my teeth with this bug. Is this a good starting point? If so, where should I be looking?
+
+Hi, Rohit! I am actively involved in pursuing this at the moment. I have patches that do a lot of this work, but they are not complete and did not get merged in time for 5.1. I will have to update my development branches (soon) and share that code.
+
+If you'd like to help, there are three main areas of consideration:
+
+(1) I would like to ensure that all code in ./python/qemu is 100% pylint/mypy/flake8 compliant. I have many patches for this in particular. Once it's compliant, we need to prevent regressions: This task is less well defined in my head. Ideally the package is checked pythonically (via pytest, perhaps?) as well as via hooks in the QEMU source tree itself as a `make check-python` style target that can be checked from e.g. gitlab CI.
+
+For now, the python package will live in the QEMU source tree, so it needs to function in both contexts simultaneously.
+
+I consider this a requisite for packaging our SDK because it will help us prevent a certain class of regressions. By smoothing out the API and its typing in advance, the package will be less turbulent and, if needs be, easier to refactor with confidence in the future.
+
+
+(2) The code itself needs packaging glue (setup.py et al.). I also have patches here that move ./python/qemu to ./python/qemu/core and installs this as a PEP-420 namespace package, 'qemu.core'. The idea was to add different QEMU modules over time -- possibly with different dependencies, etc.
+
+One of the ideas is for everything in ./python to be checked using the same flake8/mypy/pylint regimes for consistency; but if we were to upload any packages to PyPI, I want to be able to upload them separately. e.g.
+
+./python/qemu/core ==> PyPI "qemu"
+./python/qemu/qapi ==> PyPI "qemu.qapi"
+
+I didn't figure out how facilitate that just yet -- at the moment, any subpackages present in-tree get uploaded as part of the core API, and that's not what I wanted to do. Some subpackages we create are going to be ones we don't want to ever upload to PyPI, but having them in a standard package form will help with regression testing and development in-tree.
+
+
+(3) Versioning is a complex topic and needs some consensus.
+
+- Do we version the subpackages separately, or should they use the parent QEMU version?
+- Should we release point fixes, or only release alongside official QEMU releases?
+- How do we indicate beta status? If we release at version 5.2, people might expect SDK API stability, but we can't promise that yet!
+- QEMU does not use semver, but Python ecosystem largely does. The QEMU deprecation policy may not mesh well with Python's expected behavior.
+
+There's a lot there to think about before we push a package to PyPI. Pushing to PyPI, however, is not a requisite for accomplishing the first two tasks -- so we can shelf this for a little bit.
+
+
+If you have some experience with python packaging and distribution and would like to help, let me know. You can sign up for the qemu development mailing list [1], and send a mail introducing yourself and CC the following folks:
+
+John Snow <email address hidden>
+Cleber Rosa <email address hidden>
+Eduardo Habkost <email address hidden>
+
+Thanks,
+--js
+
+
+[1] https://lists.gnu.org/mailman/listinfo/qemu-devel
+
+
+This is an automated cleanup. This bug report has been moved
+to QEMU's new bug tracker on gitlab.com and thus gets marked
+as 'expired' now. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/50
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1878501 b/results/classifier/zero-shot/118/peripherals/1878501
new file mode 100644
index 00000000..bfba13de
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1878501
@@ -0,0 +1,108 @@
+architecture: 0.935
+peripherals: 0.926
+graphic: 0.924
+i386: 0.913
+user-level: 0.910
+mistranslation: 0.899
+risc-v: 0.885
+device: 0.869
+ppc: 0.858
+files: 0.857
+hypervisor: 0.846
+permissions: 0.834
+x86: 0.830
+kernel: 0.826
+PID: 0.822
+performance: 0.821
+arm: 0.811
+assembly: 0.804
+vnc: 0.801
+debug: 0.800
+semantic: 0.786
+socket: 0.778
+TCG: 0.767
+network: 0.754
+register: 0.713
+virtual: 0.660
+VMM: 0.629
+KVM: 0.619
+boot: 0.541
+
+qemu-i386 does not define AT_SYSINFO
+
+qemu-i386 does not define the AT_SYSINFO auxval when running i386 Linux binaries.
+
+On most libcs, this is properly handled, but this is mandatory for the i686 Bionic (Android) libc or it will segfault.
+
+This is due to a blind assumption that getauxval(AT_SYSINFO) will return a valid function pointer:
+
+The code varies from version to version, but it looks like this:
+
+void *__libc_sysinfo;
+// mangled as _Z19__libc_init_sysinfov
+void __libc_init_sysinfo() {
+  bool dummy;
+  // __bionic_getauxval = getauxval
+  __libc_sysinfo = reinterpret_cast<void *>(__bionic_getauxval(AT_SYSINFO, dummy));
+}
+
+A simple way to reproduce is to compile a basic C program against the NDK:
+
+int main(void) { return 0; }
+
+$ i686-linux-android-clang -static empty.c -o empty
+$ qemu-i386 -cpu max ./empty
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+The place where it segfaults is misleading: It will, at least on the current NDK, crash on __set_thread_area, this is due to it calling a function pointer to __libc_sysinfo returned by __kernel_syscall.
+
+QEMU 4.1.1 (aarch64)
+Pixel 2 XL via Termux
+
+Richard,
+
+this problem seems related to the work you already done on vsyscalls:
+
+  b26491b4d4f8 ("linux-user/i386: Emulate x86_64 vsyscalls")
+
+I don't know if we should support AT_SYSINFO or consider this as a bug of the target libc.
+
+We do not define AT_SYSINFO because we do not implement the vdso.
+All we have so far is the vsyscall page, which is not the same thing.
+
+I've had patches for the vdso for a number of years; perhaps it's
+time to update and re-send that...
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1881506 b/results/classifier/zero-shot/118/peripherals/1881506
new file mode 100644
index 00000000..c07a356f
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1881506
@@ -0,0 +1,66 @@
+TCG: 0.948
+peripherals: 0.947
+architecture: 0.908
+x86: 0.899
+graphic: 0.873
+kernel: 0.851
+user-level: 0.850
+debug: 0.844
+boot: 0.826
+semantic: 0.773
+device: 0.763
+performance: 0.753
+ppc: 0.727
+permissions: 0.720
+files: 0.691
+hypervisor: 0.650
+assembly: 0.637
+mistranslation: 0.628
+network: 0.602
+socket: 0.593
+vnc: 0.571
+risc-v: 0.547
+register: 0.541
+i386: 0.541
+arm: 0.528
+PID: 0.515
+virtual: 0.430
+VMM: 0.406
+KVM: 0.363
+
+TCG doesn't support a lot of features that should be supported
+
+This is quite odd, and I'm not sure about how to get around it. I'm writing an OS in Rust and require APIC support. When I boot my kernel with qemu-system-x86_64, however, it dumps out a [lot] of warnings; it claims that TCG doesn't support FMA, X2APIC, AVX, F16C, AVX2, RDSEED, SHA-NI, FXSR-OPT, misalignsse, 3dnowprefetch, osvw, topoext, perfctr-core, clzero, xsaveerptr, ibpb, nrip-save, xsavec, and xsaves, but prints these warnings over 80 times before finally doing what I told it to do. Running QEMU 5.0.0 (unknown commit hash), as follows:
+qemu-system-x86_64 -drive format=raw,file=target\x86_64-kernel-none\debug\bootimage-kernel.bin -serial stdio -no-reboot -hdb disk.img -s -m 4G -usb -rtc base=utc,clock=host -cpu EPYC-v3,+acpi,+apic,+rdrand,+rdseed,+sse,+sse2,+sse4.1,+sse4.2,+sse4a,+ssse3,+syscall,+x2apic -smp cpus=8 -soundhw all
+I would run using HAXM, but my kernel requires RDRAND, and QEMU does not, to my knowledge, automatically support RDRAND (and I don't know how to enable it).
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1883268 b/results/classifier/zero-shot/118/peripherals/1883268
new file mode 100644
index 00000000..61d27c6d
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1883268
@@ -0,0 +1,129 @@
+peripherals: 0.895
+permissions: 0.893
+semantic: 0.890
+graphic: 0.883
+register: 0.883
+assembly: 0.880
+device: 0.868
+architecture: 0.867
+mistranslation: 0.865
+performance: 0.865
+arm: 0.856
+risc-v: 0.851
+user-level: 0.848
+socket: 0.841
+kernel: 0.838
+debug: 0.837
+TCG: 0.837
+PID: 0.829
+hypervisor: 0.811
+boot: 0.810
+network: 0.808
+vnc: 0.787
+files: 0.773
+ppc: 0.771
+virtual: 0.768
+x86: 0.758
+VMM: 0.758
+KVM: 0.694
+i386: 0.614
+
+random errors on aarch64 when executing __aarch64_cas8_acq_rel
+
+Hello,
+
+Since I upgraded to qemu-5.0 when executing the GCC testsuite,
+I've noticed random failures of g++.dg/ext/sync-4.C.
+
+I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57 -R 0 -d in_asm,int,exec,cpu,unimp,guest_errors,nochain)
+
+The traces where generated by a CI build, I built the executable manually but I expect it to be the same as the one executed by CI.
+
+In seems the problem occurs in f13, which leads to a call to abort()
+
+The preprocessed version of f13/t13 are as follows:
+static bool f13 (void *p) __attribute__ ((noinline));
+static bool f13 (void *p)
+{
+  return (__sync_bool_compare_and_swap((ditype*)p, 1, 2));
+}
+static void t13 ()
+{
+  try {
+    f13(0);
+  }
+  catch (...) {
+    return;
+  }
+  abort();
+}
+
+
+When looking at the execution traces at address 0x00400c9c, main calls f13, which in turn calls __aarch64_cas8_acq_rel (at 0x00401084)
+__aarch64_cas8_acq_rel returns to f13 (address 0x0040113c), then f13 returns to main (0x0040108c) which then calls abort (0x00400ca0)
+
+I'm not quite sure what's wrong :-(
+
+I've not noticed such random problems with native aarch64 hardware.
+
+
+
+
+
+
+
+FWIW, I cannot reproduce the problem with x86_64 host,
+but I can reproduce it on a 32-bit i686 host.
+
+There's nothing wrong with the atomic operation, which
+makes sense since it's against a NULL pointer.  The
+problem that I see is in the unwinding -- the catch
+never happens and std::terminate gets called.
+
+There must be some sort of 32-bit TCG error though,
+because the same binary works on x86_64 host.
+
+The most confusing thing about this test case is that
+12 previous throws work correctly, but the 13th fails.
+
+Hi Richard,
+
+Thanks for taking a look and confirming that you managed to reproduce the problem.
+I forgot to mention that I'm using x86_64 hosts, not i686. I hope there are not two unrelated issues...
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+Opened ticket on gitlab: https://gitlab.com/qemu-project/qemu/-/issues/333
+
+
+Thanks for moving the ticket to gitlab! ... so I'm closing this on Launchpad now.
+
diff --git a/results/classifier/zero-shot/118/peripherals/1886097 b/results/classifier/zero-shot/118/peripherals/1886097
new file mode 100644
index 00000000..465e2880
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1886097
@@ -0,0 +1,101 @@
+peripherals: 0.846
+user-level: 0.818
+mistranslation: 0.806
+semantic: 0.774
+graphic: 0.769
+debug: 0.742
+hypervisor: 0.741
+assembly: 0.713
+risc-v: 0.705
+architecture: 0.704
+permissions: 0.703
+VMM: 0.693
+network: 0.673
+ppc: 0.672
+vnc: 0.670
+device: 0.661
+virtual: 0.655
+performance: 0.653
+kernel: 0.648
+TCG: 0.645
+arm: 0.602
+register: 0.602
+PID: 0.600
+KVM: 0.571
+x86: 0.550
+socket: 0.547
+boot: 0.514
+files: 0.469
+i386: 0.308
+
+Error in user-mode calculation of ELF program's brk
+
+There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments:
+
+  Program Headers:
+    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
+    EXIDX          0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R   0x4
+    PHDR           0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R   0x1000
+    LOAD           0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R   0x1000
+    LOAD           0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000
+    LOAD           0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x10000
+    NOTE           0x000114 0x00010114 0x00010114 0x00044 0x00044 R   0x4
+    TLS            0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
+    GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x8
+    GNU_RELRO      0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R   0x1
+    LOAD           0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000
+    LOAD           0x098000 0x00030000 0x00030000 0x01000 0x01000 RW  0x1000
+
+The call to set_brk in Linux's binfmt_elf.c receives these arguments:
+
+  set_brk(0xa3160, 0xa3160, 1)
+  
+Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case).
+
+I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is
+
+  LOAD           0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW  0x10000
+    
+which overlaps with the TLS segment:
+
+    TLS            0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R   0x4
+    
+However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/276
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1888492 b/results/classifier/zero-shot/118/peripherals/1888492
new file mode 100644
index 00000000..cfca8864
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1888492
@@ -0,0 +1,99 @@
+peripherals: 0.842
+mistranslation: 0.800
+device: 0.796
+architecture: 0.788
+risc-v: 0.779
+user-level: 0.765
+arm: 0.748
+permissions: 0.731
+hypervisor: 0.724
+boot: 0.709
+register: 0.708
+graphic: 0.694
+ppc: 0.692
+socket: 0.681
+semantic: 0.675
+network: 0.668
+debug: 0.654
+x86: 0.653
+kernel: 0.651
+vnc: 0.642
+TCG: 0.640
+virtual: 0.634
+PID: 0.615
+assembly: 0.615
+performance: 0.607
+files: 0.603
+KVM: 0.537
+VMM: 0.531
+i386: 0.397
+
+After installing Ubuntu, restart and pop up the CMD command prompt
+
+QEMU release version： V5.1.0
+time：2020年7月22日10:34:40
+Operation: 安装完Ubuntu后重新启动，并弹出CMD命令提示符
+Question:
+Command used：qemu-system-x86_64.exe -name test -m 4096 -machine accel=hax -cdrom .\workspace\ubuntu\ubuntu-20.04-desktop-amd64.iso .\workspace\img\ubuntu.img
+HAX is working and emulator runs in fast virt mode.
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+*** BUG ***
+In pixman_region32_init_rect: Invalid rectangle passed
+Set a breakpoint on '_pixman_log_error' to debug
+
+
+(qemu:660): Gtk-WARNING **: Negative content width -7 (allocation 1, extents 4x4) while allocating gadget (node headerbar, owner GtkHeaderBar)
+
+(qemu:660): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -102 and height 16
+
+(qemu:660): Gtk-WARNING **: Negative content width -23 (allocation 1, extents 12x12) while allocating gadget (node label, owner GtkLabel)
+qemu-system-x86_64.exe: Gtk: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1889943 b/results/classifier/zero-shot/118/peripherals/1889943
new file mode 100644
index 00000000..ea83fb93
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1889943
@@ -0,0 +1,398 @@
+peripherals: 0.873
+semantic: 0.839
+permissions: 0.838
+user-level: 0.828
+graphic: 0.822
+risc-v: 0.821
+virtual: 0.817
+performance: 0.814
+architecture: 0.808
+VMM: 0.802
+hypervisor: 0.799
+arm: 0.796
+TCG: 0.796
+assembly: 0.795
+vnc: 0.795
+network: 0.793
+register: 0.786
+device: 0.784
+KVM: 0.779
+PID: 0.778
+socket: 0.776
+debug: 0.768
+boot: 0.761
+kernel: 0.758
+i386: 0.758
+ppc: 0.749
+x86: 0.715
+files: 0.697
+mistranslation: 0.663
+
+Improper TCP/IP packet splitting on e1000e/vmxnet3
+
+Problem Description:
+When using a tap interface and the guest sends a TCP packet that would need to be segmented, it is fragmented using IP fragmentation. The host does not reassemble the IP fragments and forwards them to the next hop. This causes issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios). 
+This issue occurs on the e1000e and vmxnet3 NIC models, and possibly others. It does not occur on the virtio(which passes the entire packet through to the host w/o fragmentation or segmentation) or the e1000 model(). 
+
+Test scenario:
+Setup a tap and network bridge using the directions here: https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c
+Boot the machine into any modern guest(a Fedora 31 live iso was used for testing)
+Begin a wireshark capture on the host machine
+On the host(or another machine on the network) run: npx http-echo-server(See https://github.com/watson/http-echo-server)
+On the guest run
+Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu. Suspendisse vehicula congue ante, non rhoncus elit tempus vitae. Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies. Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis. Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta ut. Phasellus at quam bibendum, fermentum libero sit amet, ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus ligula, hendrerit nec aliquam non, finibus a turpis. Proin scelerisque convallis ante, et pharetra elit. Donec nunc nisl, viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis neque posuere placerat quis quis massa. Donec quis lacus ligula. Donec mollis vel nisi eget elementum. Nam id magna porta nunc consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor mattis. Praesent in mattis tortor. In venenatis convallis quam, in posuere nibh. Proin non dignissim massa. Cras at mi ut lorem tristique fringilla. Nulla ac quam condimentum metus tincidunt vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus condimentum, arcu sem molestie augue, in suscipit mauris odio mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan urna maximus. Nam nec odio volutpat, varius est id, tempus libero. Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in. Etiam tempor, est sit amet vulputate molestie, urna neque sodales leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor dapibus maximus faucibus ut erat. Ut pharetra tempor massa in bibendum. Interdum et malesuada fames ac ante ipsum primis in faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet volutpat egestas, est est pulvinar erat, sed luctus nisl ligula eget justo vestibulum.” <ECHOSERVERIP:PORT>
+
+2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/
+
+Compare results from an e1000, a virtio, and a e1000e card:
++--------+-----------+---------+------------+
+| Model  | Fragment  | Segment | Wire Size  |
++--------+-----------+---------+------------+
+| e1000e | Yes       | NO      | 1484 + 621 |
++--------+-----------+---------+------------+
+| e1000  | No        | Yes     | 1516 + 620 |
++--------+-----------+---------+------------+
+| Virtio | NO        | NO      | 2068       |
++--------+-----------+---------+------------+
+
+Expected Results:
+TCP Segment to proper size OR pass full size to host and let the host split if necessary.
+
+Configuration changes that did not work:
+Disable host, guest, router firewalls
+Different Hosts
+Different Physical NICs
+Libvirt based NAT/Routed modes
+Fedora 32 vs 31
+Qemu 4.2.0 vs github commit d74824cf7c8b352f9045e949dc636c7207a41eee
+
+System Information:
+lsb_release -rd
+Description:	Fedora release 32 (Thirty Two)
+Release:	32
+
+uname -a
+Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
+
+I can provide additional logs, debug info, etc. if needed.
+
+After reading through some of the code for the e1000, e1000e, and vmxnet3 device models, it appears that all 3 are capable of performing tcp segementation, however, in the net_tx_pkt_send function, there is a check   
+
+if (pkt->has_virt_hdr ||
+        pkt->virt_hdr.gso_type == VIRTIO_NET_HDR_GSO_NONE)
+
+that if true will send the tcp segmented packets. However, if false, it will do IP fragmentation instead. I could not easily decipher what determines whether or not the pkt->has_virt_hdr value would be true or false. 
+What differs is that in the e1000, there is no such check. It directly calls qemu_send_packet without first going through the net_tx_pkt_send.
+I will have to add in some debug prints on my local build to confirm that the tcp fragments are being created and then ignored. 
+
+After stepping through the code, it has become clear that the e1000e/vmxnet3 emulated models do not implement TCP segmentation, however they still "advertise" it as a feature to the guest OS. 
+
+Regarding my prior interpretation, the implementation is written to forward the entire packet to the host OS if the has_vnet_hdr variable is set, which is passed all the way up from the IFF_VNET_HDR on the tap/tun interface. I am not sure what the kernel considers when setting that flag, but it appears that it is true when in a host-only configuration, and false otherwise. I may look into the virtio implementation to see how it affects that because they are linked. 
+
+In order to fix this, it would likely be possible to modify the net_tx_pkt_do_sw_fragmentation function in net_tx_pkt.c to incorporate the full set of offloads, not just ipv4. 
+
+Because both the e1000e and the vmxnet3 implmentations share net_tx_pkt functions, this could fix both.
+
+Some more clarifications:
+It appears the QEMU does turn on the vnet_hdr flag of the tap interface in most cases, not just host-only networks. My previous assumption was due to the way the libvirt manages it, only setting it if the virtio interface is used.
+
+Still, for software fragmentation implementations, ip fragmentation should be a last resort.
+
+I have also confirmed a suspicion that the current implementation of sw fragmentation will not work with IPV6. It creates malformed packets as ipv6 requires a different setup of headers to fragment. Thanks to the many redundancies in the network stack, the packets eventually arrive at the host server correctly formed, but we should not rely on this fact.
+
+Hello Yan,
+
+I tryed the patches mentioned(the first one was already implemented in
+the git master, the second wasn't). It did fix the IPv6 fragmentation
+issue. So therefore, the focus needs to be on implementing proper layer
+4 segmentation. 
+
+--Patrick
+On Mon, 2020-08-03 at 09:37 +0300, Yan Vugenfirer wrote:
+> Hello Patrick,
+> 
+> If you are using  QEMU version 4.2, then it is missing recent patches
+> fixing IPv6 and TSO behaviour:
+> https://<email address hidden>/msg723411.html
+> https://<email address hidden>/msg723412.html
+> 
+> Can you check that the above patches solve your issues?
+> 
+> 
+> Best regards,
+> Yan.
+> 
+> > On 2 Aug 2020, at 6:59 PM, Patrick Magauran <
+> > <email address hidden>> wrote:
+> > 
+> > Some more clarifications:
+> > It appears the QEMU does turn on the vnet_hdr flag of the tap
+> > interface in most cases, not just host-only networks. My previous
+> > assumption was due to the way the libvirt manages it, only setting
+> > it if the virtio interface is used.
+> > 
+> > Still, for software fragmentation implementations, ip fragmentation
+> > should be a last resort.
+> > 
+> > I have also confirmed a suspicion that the current implementation
+> > of sw
+> > fragmentation will not work with IPV6. It creates malformed packets
+> > as
+> > ipv6 requires a different setup of headers to fragment. Thanks to
+> > the
+> > many redundancies in the network stack, the packets eventually
+> > arrive at
+> > the host server correctly formed, but we should not rely on this
+> > fact.
+> > 
+> > ** Description changed:
+> > 
+> > + Update: The sw implementation of fragmentation also creates
+> > malformed
+> > + IPv6 packets when their size is above the MTU. See comment #3
+> > + 
+> >  Problem Description:
+> > - When using a tap interface and the guest sends a TCP packet that
+> > would need to be segmented, it is fragmented using IP
+> > fragmentation. The host does not reassemble the IP fragments and
+> > forwards them to the next hop. This causes issues on certain ISPs,
+> > which seemingly reject IP fragments(Verizon Fios). 
+> > - This issue occurs on the e1000e and vmxnet3 NIC models, and
+> > possibly others. It does not occur on the virtio(which passes the
+> > entire packet through to the host w/o fragmentation or
+> > segmentation) or the e1000 model(). 
+> > + When using a tap interface and the guest sends a TCP packet that
+> > would need to be segmented, it is fragmented using IP
+> > fragmentation. The host does not reassemble the IP fragments and
+> > forwards them to the next hop. This causes issues on certain ISPs,
+> > which seemingly reject IP fragments(Verizon Fios).
+> > + This issue occurs on the e1000e and vmxnet3 NIC models, and
+> > possibly others. It does not occur on the virtio(which passes the
+> > entire packet through to the host w/o fragmentation or
+> > segmentation) or the e1000 model().
+> > 
+> >  Test scenario:
+> >  Setup a tap and network bridge using the directions here: 
+> > https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c
+> >  Boot the machine into any modern guest(a Fedora 31 live iso was
+> > used for testing)
+> >  Begin a wireshark capture on the host machine
+> >  On the host(or another machine on the network) run: npx http-echo-
+> > server(See https://github.com/watson/http-echo-server)
+> >  On the guest run
+> >  Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit.
+> > Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu.
+> > Suspendisse vehicula congue ante, non rhoncus elit tempus vitae.
+> > Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies.
+> > Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis.
+> > Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus
+> > sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta
+> > ut. Phasellus at quam bibendum, fermentum libero sit amet,
+> > ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus
+> > ligula, hendrerit nec aliquam non, finibus a turpis. Proin
+> > scelerisque convallis ante, et pharetra elit. Donec nunc nisl,
+> > viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis
+> > neque posuere placerat quis quis massa. Donec quis lacus ligula.
+> > Donec mollis vel nisi eget elementum. Nam id magna porta nunc
+> > consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor
+> > mattis. Praesent in mattis tortor. In venenatis convallis quam, in
+> > posuere nibh. Proin non dignissim massa. Cras at mi ut lorem
+> > tristique fringilla. Nulla ac quam condimentum metus tincidunt
+> > vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus
+> > condimentum, arcu sem molestie augue, in suscipit mauris odio
+> > mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan
+> > urna maximus. Nam nec odio volutpat, varius est id, tempus libero.
+> > Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in.
+> > Etiam tempor, est sit amet vulputate molestie, urna neque sodales
+> > leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor
+> > dapibus maximus faucibus ut erat. Ut pharetra tempor massa in
+> > bibendum. Interdum et malesuada fames ac ante ipsum primis in
+> > faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt
+> > consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus
+> > pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet
+> > volutpat egestas, est est pulvinar erat, sed luctus nisl ligula
+> > eget justo vestibulum.” <ECHOSERVERIP:PORT>
+> > 
+> >  2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/
+> > 
+> >  Compare results from an e1000, a virtio, and a e1000e card:
+> >  +--------+-----------+---------+------------+
+> >  | Model  | Fragment  | Segment | Wire Size  |
+> >  +--------+-----------+---------+------------+
+> >  | e1000e | Yes       | NO      | 1484 + 621 |
+> >  +--------+-----------+---------+------------+
+> >  | e1000  | No        | Yes     | 1516 + 620 |
+> >  +--------+-----------+---------+------------+
+> >  | Virtio | NO        | NO      | 2068       |
+> >  +--------+-----------+---------+------------+
+> > 
+> >  Expected Results:
+> >  TCP Segment to proper size OR pass full size to host and let the
+> > host split if necessary.
+> > 
+> >  Configuration changes that did not work:
+> >  Disable host, guest, router firewalls
+> >  Different Hosts
+> >  Different Physical NICs
+> >  Libvirt based NAT/Routed modes
+> >  Fedora 32 vs 31
+> >  Qemu 4.2.0 vs github commit
+> > d74824cf7c8b352f9045e949dc636c7207a41eee
+> > 
+> >  System Information:
+> >  lsb_release -rd
+> >  Description:	Fedora release 32 (Thirty Two)
+> >  Release:	32
+> > 
+> >  uname -a
+> >  Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23
+> > 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
+> > 
+> >  I can provide additional logs, debug info, etc. if needed.
+> > 
+> > -- 
+> > You received this bug notification because you are a member of
+> > qemu-
+> > devel-ml, which is subscribed to QEMU.
+> > https://bugs.launchpad.net/bugs/1889943
+> > 
+> > Title:
+> >  Improper TCP/IP packet splitting on e1000e/vmxnet3
+> > 
+> > Status in QEMU:
+> >  New
+> > 
+> > Bug description:
+> >  Update: The sw implementation of fragmentation also creates
+> > malformed
+> >  IPv6 packets when their size is above the MTU. See comment #3
+> > 
+> >  Problem Description:
+> >  When using a tap interface and the guest sends a TCP packet that
+> > would need to be segmented, it is fragmented using IP
+> > fragmentation. The host does not reassemble the IP fragments and
+> > forwards them to the next hop. This causes issues on certain ISPs,
+> > which seemingly reject IP fragments(Verizon Fios).
+> >  This issue occurs on the e1000e and vmxnet3 NIC models, and
+> > possibly others. It does not occur on the virtio(which passes the
+> > entire packet through to the host w/o fragmentation or
+> > segmentation) or the e1000 model().
+> > 
+> >  Test scenario:
+> >  Setup a tap and network bridge using the directions here: 
+> > https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c
+> >  Boot the machine into any modern guest(a Fedora 31 live iso was
+> > used for testing)
+> >  Begin a wireshark capture on the host machine
+> >  On the host(or another machine on the network) run: npx http-echo-
+> > server(See https://github.com/watson/http-echo-server)
+> >  On the guest run
+> >  Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit.
+> > Maecenas venenatis viverra ipsum, ac tincidunt est rhoncus eu.
+> > Suspendisse vehicula congue ante, non rhoncus elit tempus vitae.
+> > Duis ac leo massa. Donec rutrum condimentum turpis nec ultricies.
+> > Duis laoreet elit eu arcu pulvinar, vitae congue neque mattis.
+> > Mauris sed ante nunc. Vestibulum vitae urna a tellus maximus
+> > sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta
+> > ut. Phasellus at quam bibendum, fermentum libero sit amet,
+> > ullamcorper mauris. In rutrum sit amet dui id maximus. Ut lectus
+> > ligula, hendrerit nec aliquam non, finibus a turpis. Proin
+> > scelerisque convallis ante, et pharetra elit. Donec nunc nisl,
+> > viverra vitae dui at, posuere rhoncus nibh. Mauris in massa quis
+> > neque posuere placerat quis quis massa. Donec quis lacus ligula.
+> > Donec mollis vel nisi eget elementum. Nam id magna porta nunc
+> > consectetur efficitur ac quis lorem. Cras faucibus vel ex porttitor
+> > mattis. Praesent in mattis tortor. In venenatis convallis quam, in
+> > posuere nibh. Proin non dignissim massa. Cras at mi ut lorem
+> > tristique fringilla. Nulla ac quam condimentum metus tincidunt
+> > vulputate ut at leo. Nunc pellentesque, nunc vel rhoncus
+> > condimentum, arcu sem molestie augue, in suscipit mauris odio
+> > mollis odio. Integer hendrerit lectus a leo facilisis, in accumsan
+> > urna maximus. Nam nec odio volutpat, varius est id, tempus libero.
+> > Vestibulum lobortis tortor quam, ac scelerisque urna rhoncus in.
+> > Etiam tempor, est sit amet vulputate molestie, urna neque sodales
+> > leo, sit amet blandit risus felis sed est. Nulla eu eros nec tortor
+> > dapibus maximus faucibus ut erat. Ut pharetra tempor massa in
+> > bibendum. Interdum et malesuada fames ac ante ipsum primis in
+> > faucibus. Etiam mattis molestie felis eu efficitur. Morbi tincidunt
+> > consectetur diam tincidunt feugiat. Morbi euismod ut lorem finibus
+> > pellentesque. Aliquam eu porta ex. Aliquam cursus, orci sit amet
+> > volutpat egestas, est est pulvinar erat, sed luctus nisl ligula
+> > eget justo vestibulum.” <ECHOSERVERIP:PORT>
+> > 
+> >  2000 bytes of Lorem Ipsum taken from https://www.lipsum.com/
+> > 
+> >  Compare results from an e1000, a virtio, and a e1000e card:
+> >  +--------+-----------+---------+------------+
+> >  | Model  | Fragment  | Segment | Wire Size  |
+> >  +--------+-----------+---------+------------+
+> >  | e1000e | Yes       | NO      | 1484 + 621 |
+> >  +--------+-----------+---------+------------+
+> >  | e1000  | No        | Yes     | 1516 + 620 |
+> >  +--------+-----------+---------+------------+
+> >  | Virtio | NO        | NO      | 2068       |
+> >  +--------+-----------+---------+------------+
+> > 
+> >  Expected Results:
+> >  TCP Segment to proper size OR pass full size to host and let the
+> > host split if necessary.
+> > 
+> >  Configuration changes that did not work:
+> >  Disable host, guest, router firewalls
+> >  Different Hosts
+> >  Different Physical NICs
+> >  Libvirt based NAT/Routed modes
+> >  Fedora 32 vs 31
+> >  Qemu 4.2.0 vs github commit
+> > d74824cf7c8b352f9045e949dc636c7207a41eee
+> > 
+> >  System Information:
+> >  lsb_release -rd
+> >  Description:	Fedora release 32 (Thirty Two)
+> >  Release:	32
+> > 
+> >  uname -a
+> >  Linux pats-laptop-linux 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul 23
+> > 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
+> > 
+> >  I can provide additional logs, debug info, etc. if needed.
+> > 
+> > To manage notifications about this bug go to:
+> > https://bugs.launchpad.net/qemu/+bug/1889943/+subscriptions
+> > 
+> 
+> 
+
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/1890155 b/results/classifier/zero-shot/118/peripherals/1890155
new file mode 100644
index 00000000..d07ba593
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1890155
@@ -0,0 +1,79 @@
+peripherals: 0.812
+graphic: 0.741
+device: 0.740
+risc-v: 0.739
+hypervisor: 0.732
+permissions: 0.720
+user-level: 0.717
+i386: 0.708
+x86: 0.684
+debug: 0.653
+ppc: 0.634
+PID: 0.633
+arm: 0.633
+semantic: 0.622
+VMM: 0.617
+virtual: 0.611
+vnc: 0.609
+architecture: 0.606
+TCG: 0.603
+network: 0.594
+register: 0.586
+KVM: 0.569
+boot: 0.550
+socket: 0.549
+files: 0.527
+kernel: 0.523
+mistranslation: 0.523
+performance: 0.495
+assembly: 0.424
+
+Abort in vmxnet3_validate_interrupt_idx
+
+Hello,
+Reproducer:
+
+cat << EOF | ./i386-softmmu/qemu-system-i386 \
+-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic
+outl 0xcf8 0x80001014
+outl 0xcfc 0xe0001000
+outl 0xcf8 0x80001018
+outl 0xcf8 0x80001004
+outw 0xcfc 0x7
+write 0x0 0x1 0xe1
+write 0x1 0x1 0xfe
+write 0x2 0x1 0xbe
+write 0x3 0x1 0xba
+write 0x52 0x1 0x61
+writeq 0xe0001020 0xef0bff5ecafe0000
+EOF
+
+==============================================================
+ #7 0x55b271a89b67 in hw_error /home/alxndr/Development/qemu/general-fuzz/softmmu/cpus.c:927:5
+ #8 0x55b272fc6433 in vmxnet3_validate_interrupt_idx /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1355:9
+ #9 0x55b272fc4e6d in vmxnet3_validate_interrupts /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1364:5
+ #10 0x55b272fbe723 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1546:5
+ #11 0x55b272fb6fba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9
+ #12 0x55b272fb410f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9
+ #13 0x55b271ac4193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5
+ #14 0x55b271ac3637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18
+ #15 0x55b271ac1256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16
+ #16 0x55b270e724a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23
+ #17 0x55b270e5acc6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14
+
+
+qemu: hardware error: Bad interrupt index: 97
+Aborted
+
+-Alex
+
+This still reproduces with the current version of QEMU. Marking as "Confirmed"
+
+I moved this report over to QEMU's new bug tracker on gitlab.com.
+Please continue with the discussion here:
+
+https://gitlab.com/qemu-project/qemu/-/issues/539
+
+Thanks for moving it over! ... let's close this one here on Launchpad now.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1893003 b/results/classifier/zero-shot/118/peripherals/1893003
new file mode 100644
index 00000000..ebc5e99a
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1893003
@@ -0,0 +1,109 @@
+peripherals: 0.873
+debug: 0.865
+semantic: 0.863
+hypervisor: 0.859
+graphic: 0.856
+user-level: 0.828
+architecture: 0.822
+permissions: 0.820
+TCG: 0.815
+mistranslation: 0.806
+ppc: 0.796
+performance: 0.794
+register: 0.788
+device: 0.784
+virtual: 0.782
+arm: 0.776
+assembly: 0.774
+risc-v: 0.767
+boot: 0.749
+x86: 0.743
+vnc: 0.727
+files: 0.722
+VMM: 0.721
+socket: 0.707
+PID: 0.704
+KVM: 0.703
+kernel: 0.695
+network: 0.673
+i386: 0.493
+
+qemu linux-user doesn't translate host/target data for iovec I/O
+
+When using iovec I/O functions (like `readv`), no data translation happens. I'm hitting this issue with libevent upon constructing a bufferevent over an inotify descriptor, and then building for either ppc64 or s390x (both big-endian) on x86_64 (little-endian) and running resulting code with qemu-ppc64 or qemu-s390x on Gentoo using latest QEMU version available (5.0.0-r2).
+
+The code in question is in https://github.com/transmission/transmission/blob/master/libtransmission/watchdir-inotify.c (`tr_watchdir_inotify_new`, `tr_watchdir_inotify_on_event`).
+
+While `read` syscall is handled properly, `readv` (which libevent is using in my case) doesn't have any logic to call `host_to_target_data_inotify` or any other translation function, leaving inotify data unchanged (with values in little-endian), which then leads to unit test failures. Quoting `do_syscall1` implementation bits for the reference:
+
+---8<---begin---
+    case TARGET_NR_read:
+        if (arg2 == 0 && arg3 == 0) {
+            return get_errno(safe_read(arg1, 0, 0));
+        } else {
+            if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
+                return -TARGET_EFAULT;
+            ret = get_errno(safe_read(arg1, p, arg3));
+            if (ret >= 0 &&
+                fd_trans_host_to_target_data(arg1)) {
+                ret = fd_trans_host_to_target_data(arg1)(p, ret);
+            }
+            unlock_user(p, arg2, ret);
+        }
+        return ret;
+...
+    case TARGET_NR_readv:
+        {
+            struct iovec *vec = lock_iovec(VERIFY_WRITE, arg2, arg3, 0);
+            if (vec != NULL) {
+                ret = get_errno(safe_readv(arg1, vec, arg3));
+                unlock_iovec(vec, arg2, arg3, 1);
+            } else {
+                ret = -host_to_target_errno(errno);
+            }
+        }
+        return ret;
+---8<---end---
+
+To reiterate, the issue is not only with `readv` but with other iovec functions as well.
+
+The attached patch fixes the issue for me, but is incomplete (and not thoroughly tested) as I've only implemented inotify data translation for readv syscall.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/426
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1907817 b/results/classifier/zero-shot/118/peripherals/1907817
new file mode 100644
index 00000000..5d526517
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1907817
@@ -0,0 +1,82 @@
+peripherals: 0.835
+TCG: 0.813
+x86: 0.812
+ppc: 0.806
+vnc: 0.798
+hypervisor: 0.784
+VMM: 0.783
+user-level: 0.780
+i386: 0.770
+KVM: 0.754
+virtual: 0.750
+mistranslation: 0.747
+permissions: 0.711
+graphic: 0.701
+performance: 0.693
+debug: 0.688
+files: 0.683
+risc-v: 0.682
+device: 0.681
+register: 0.674
+network: 0.665
+arm: 0.660
+architecture: 0.658
+semantic: 0.656
+PID: 0.651
+assembly: 0.648
+kernel: 0.639
+socket: 0.639
+boot: 0.609
+
+qemu-aarch64 tcg assertion v5.2.0
+
+After updating to 5.2 I am getting following assertion error:
+qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & max_align) == 0' failed.
+
+I think it was introduced by commit: e2e7168a214b0ed98dc357bba96816486a289762
+
+Becasue before this change, in function simd_desc only maxsz % 8 == 0 was checked, but after this change qemu check for following:
+ 
+max_align = maxsz >= 16 ? 15 : 7;
+tcg_debug_assert((maxsz & max_align) == 0);  <--- here assertion happens
+
+in my case maxsz=56.
+
+
+Whole backtrace:
+#4  0x0000004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at ../tcg/tcg-op-gvec.c:54
+#5  0x0000004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at ../tcg/tcg-op-gvec.c:89
+#6  0x0000004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630
+#7  0x00000040003164d0 in expand_clr (dofs=3144, maxsz=56) at ../tcg/tcg-op-gvec.c:679
+#8  0x0000004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538
+#9  0x0000004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at ../target/arm/translate-a64.c:592
+#10 0x0000004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at ../target/arm/translate-a64.c:600
+--Type <RET> for more, q to quit, c to continue without paging--
+#11 0x0000004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at ../target/arm/translate-a64.c:608
+#12 0x0000004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, itof=true, rmode=0, scale=64, sf=0, type=0)
+    at ../target/arm/translate-a64.c:6988
+#13 0x0000004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7299
+#14 0x0000004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7389
+#15 0x000000400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:14494
+#16 0x000000400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) at ../target/arm/translate-a64.c:14663
+#17 0x000000400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823
+#18 0x00000040002e8630 in translator_loop (ops=0x4000902e00 <aarch64_translator_ops>, db=0x40021a8180, cpu=0x7fac59b63150, 
+    tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103
+#19 0x00000040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512)
+    at ../target/arm/translate.c:9283
+#20 0x00000040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, cs_base=0, flags=2148544819, cflags=-16777216)
+    at ../accel/tcg/translate-all.c:1744
+#21 0x000000400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414
+--Type <RET> for more, q to quit, c to continue without paging--
+#22 0x000000400036b040 in cpu_exec (cpu=0x7fac59b63150) at ../accel/tcg/cpu-exec.c:770
+#23 0x0000004000113a90 in cpu_loop (env=0x7fac59b6b490) at ../linux-user/aarch64/cpu_loop.c:84
+#24 0x00000040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) at ../linux-user/main.c:864
+
+Proposed patch:
+https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04150.html
+
+I can confirm this patch fixes the issue
+
+Fix now in master as commit 6d3ef04893bde -- will be in next QEMU release.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1907938 b/results/classifier/zero-shot/118/peripherals/1907938
new file mode 100644
index 00000000..b916448c
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1907938
@@ -0,0 +1,114 @@
+mistranslation: 0.947
+peripherals: 0.920
+user-level: 0.919
+permissions: 0.900
+device: 0.892
+register: 0.888
+performance: 0.878
+x86: 0.871
+assembly: 0.856
+virtual: 0.852
+hypervisor: 0.842
+architecture: 0.841
+graphic: 0.837
+TCG: 0.824
+files: 0.820
+ppc: 0.814
+debug: 0.810
+semantic: 0.806
+arm: 0.795
+VMM: 0.792
+vnc: 0.784
+socket: 0.781
+PID: 0.778
+risc-v: 0.765
+boot: 0.764
+network: 0.762
+kernel: 0.761
+KVM: 0.757
+i386: 0.732
+
+[OSS-Fuzz] Issue 28524 virtio-blk: ASSERT: !s->dataplane_started
+
+ affects qemu
+
+=== Reproducer ===
+
+cat << EOF |./qemu-system-i386 -display none -m 512M -machine q35 \
+-device virtio-blk,drive=disk0 \
+-drive file=null-co://,id=disk0,if=none,format=raw -qtest stdio
+outl 0xcf8 0x8000181f
+outl 0xcfc 0xa044d79
+outl 0xcf8 0x80001802
+outl 0xcf8 0x80001804
+outl 0xcfc 0xb9045dff
+outl 0xcf8 0x8000180e
+outl 0xcfc 0xfb9465a
+outl 0xf85 0x9e1ea5c2
+write 0x9f002 0x1 0x04
+write 0x9f004 0x1 0x04
+write 0x9e040 0x1 0x04
+write 0x9e043 0x1 0x01
+write 0x9e048 0x1 0x10
+write 0x9e04c 0x1 0x01
+write 0x9e04e 0x1 0x6e
+write 0x1000004 0x1 0x01
+write 0x9e6e3 0x1 0x01
+write 0x9e6eb 0x1 0x04
+write 0x9e6ec 0x1 0x6e
+write 0x9f006 0x1 0x04
+write 0x9f008 0x1 0x04
+write 0x9f00a 0x1 0x04
+outl 0xf8f 0xc
+EOF
+
+=== Stack Trace ===
+
+qemu-fuzz-i386: ../hw/block/virtio-blk.c:917: void virtio_blk_reset(VirtIODevice *): Assertion `!s->dataplane_started' failed.
+==702068== ERROR: libFuzzer: deadly signal
+#0 0x55bd6fc9f311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311)
+#1 0x55bd6fbe83d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8)
+#2 0x55bd6fbce413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413)
+#3 0x7ff5241b813f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f)
+#4 0x7ff523feddb0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+#5 0x7ff523feddb0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+#6 0x7ff523fd7536 in abort stdlib/abort.c:79:7
+#7 0x7ff523fd740e in __assert_fail_base assert/assert.c:92:3
+#8 0x7ff523fe65b1 in __assert_fail assert/assert.c:101:3
+#9 0x55bd7116c435 in virtio_blk_reset hw/block/virtio-blk.c:917:5
+#10 0x55bd710c94a2 in virtio_reset hw/virtio/virtio.c:2001:9
+#11 0x55bd6ff0e0a5 in virtio_pci_reset hw/virtio/virtio-pci.c:1886:5
+#12 0x55bd6ff10686 in virtio_ioport_write hw/virtio/virtio-pci.c:339:13
+#13 0x55bd6ff10686 in virtio_pci_config_write hw/virtio/virtio-pci.c:456:9
+#14 0x55bd713fd025 in memory_region_write_accessor softmmu/memory.c:491:5
+#15 0x55bd713fca93 in access_with_adjusted_size softmmu/memory.c:552:18
+#16 0x55bd713fc2f0 in memory_region_dispatch_write softmmu/memory.c
+#17 0x55bd70e4bf36 in flatview_write_continue softmmu/physmem.c:2759:23
+#18 0x55bd70e41bbb in flatview_write softmmu/physmem.c:2799:14
+#19 0x55bd70e41bbb in address_space_write softmmu/physmem.c:2891:18
+#20 0x55bd71153462 in cpu_outl softmmu/ioport.c:80:5
+#21 0x55bd712d586e in qtest_process_command softmmu/qtest.c:483:13
+#22 0x55bd712d35bf in qtest_process_inbuf softmmu/qtest.c:797:9
+#23 0x55bd712d3315 in qtest_server_inproc_recv softmmu/qtest.c:904:9
+#24 0x55bd71910df8 in qtest_sendf tests/qtest/libqtest.c:438:5
+#25 0x55bd71911fae in qtest_out tests/qtest/libqtest.c:952:5
+#26 0x55bd71911fae in qtest_outl tests/qtest/libqtest.c:968:5
+#27 0x55bd6fcd1aa2 in op_out tests/qtest/fuzz/generic_fuzz.c:395:13
+#28 0x55bd6fcd04e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17
+#29 0x55bd6fcc9723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5
+
+OSS-Fuzz Report:
+https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28524
+
+
+
+This still reproduces with the current git version of QEMU.
+
+I moved this report over to QEMU's new bug tracker on gitlab.com.
+Please continue with the discussion here:
+
+https://gitlab.com/qemu-project/qemu/-/issues/543
+
+Thanks for moving it over! ... let's close this one here on Launchpad now.
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1910941 b/results/classifier/zero-shot/118/peripherals/1910941
new file mode 100644
index 00000000..5f4dfecf
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1910941
@@ -0,0 +1,160 @@
+peripherals: 0.809
+KVM: 0.763
+ppc: 0.758
+x86: 0.757
+hypervisor: 0.748
+VMM: 0.721
+i386: 0.717
+TCG: 0.699
+vnc: 0.689
+user-level: 0.681
+virtual: 0.653
+mistranslation: 0.642
+performance: 0.612
+graphic: 0.591
+risc-v: 0.587
+files: 0.586
+device: 0.583
+register: 0.581
+semantic: 0.567
+PID: 0.541
+architecture: 0.539
+arm: 0.539
+permissions: 0.537
+network: 0.533
+socket: 0.520
+assembly: 0.513
+kernel: 0.491
+boot: 0.483
+debug: 0.414
+
+Assertion `addr < cache->len && 2 <= cache->len - addr' in virtio-blk
+
+Hello,
+
+Using hypervisor fuzzer, hyfuzz, I found an assertion failure through virtio-blk emulator.
+
+A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service.
+
+This was found in version 5.2.0 (master)
+
+```
+
+qemu-system-i386: /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.
+[1]    1877 abort (core dumped)  /home/cwmyung/prj/hyfuzz/src/qemu-master/build/i386-softmmu/qemu-system-i386
+
+Program terminated with signal SIGABRT, Aborted.
+#0  0x00007f71cc171f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
+#1  0x00007f71cc1738b1 in __GI_abort () at abort.c:79
+#2  0x00007f71cc16342a in __assert_fail_base (fmt=0x7f71cc2eaa38 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=file@entry=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=line@entry=0x58, function=function@entry=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:92
+#3  0x00007f71cc1634a2 in __GI___assert_fail (assertion=0x56537b324230 "addr < cache->len && 2 <= cache->len - addr", file=0x56537b32425c "/home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc", line=0x58, function=0x56537b3242ab "void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *)") at assert.c:101
+#4  0x000056537af3c917 in address_space_stw_le_cached (attrs=..., result=<optimized out>, cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_cached.h.inc:88
+#5  0x000056537af3c917 in stw_le_phys_cached (cache=<optimized out>, addr=<optimized out>, val=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/exec/memory_ldst_phys.h.inc:121
+#6  0x000056537af3c917 in virtio_stw_phys_cached (vdev=<optimized out>, cache=<optimized out>, pa=<optimized out>, value=<optimized out>) at /home/cwmyung/prj/hyfuzz/src/qemu-master/include/hw/virtio/virtio-access.h:196
+#7  0x000056537af2b809 in vring_set_avail_event (vq=<optimized out>, val=0x0) at ../hw/virtio/virtio.c:429
+#8  0x000056537af2b809 in virtio_queue_split_set_notification (vq=<optimized out>, enable=<optimized out>) at ../hw/virtio/virtio.c:438
+#9  0x000056537af2b809 in virtio_queue_set_notification (vq=<optimized out>, enable=0x1) at ../hw/virtio/virtio.c:499
+#10 0x000056537b07ce1c in virtio_blk_handle_vq (s=0x56537d6bb3a0, vq=0x56537d6c0680) at ../hw/block/virtio-blk.c:795
+#11 0x000056537af3eb4d in virtio_queue_notify_aio_vq (vq=0x56537d6c0680) at ../hw/virtio/virtio.c:2326
+#12 0x000056537af3ba04 in virtio_queue_host_notifier_aio_read (n=<optimized out>) at ../hw/virtio/virtio.c:3533
+#13 0x000056537b20901c in aio_dispatch_handler (ctx=0x56537c4179f0, node=0x7f71a810b370) at ../util/aio-posix.c:329
+#14 0x000056537b20838c in aio_dispatch_handlers (ctx=<optimized out>) at ../util/aio-posix.c:372
+#15 0x000056537b20838c in aio_dispatch (ctx=0x56537c4179f0) at ../util/aio-posix.c:382
+#16 0x000056537b1f99cb in aio_ctx_dispatch (source=0x2, callback=0x7ffc8add9f90, user_data=0x0) at ../util/async.c:306
+#17 0x00007f71d1c10417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
+#18 0x000056537b1f1bab in glib_pollfds_poll () at ../util/main-loop.c:232
+#19 0x000056537b1f1bab in os_host_main_loop_wait (timeout=<optimized out>) at ../util/main-loop.c:255
+#20 0x000056537b1f1bab in main_loop_wait (nonblocking=<optimized out>) at ../util/main-loop.c:531
+#21 0x000056537af879d7 in qemu_main_loop () at ../softmmu/runstate.c:720
+#22 0x000056537a928a3b in main (argc=<optimized out>, argc@entry=0x15, argv=<optimized out>, argv@entry=0x7ffc8adda718, envp=<optimized out>) at ../softmmu/main.c:50
+#23 0x00007f71cc154b97 in __libc_start_main (main=0x56537a928a30 <main>, argc=0x15, argv=0x7ffc8adda718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc8adda708) at ../csu/libc-start.c:310
+#24 0x000056537a92894a in _start ()
+
+```
+
+To reproduce this issue, please run the QEMU with the following command line.
+
+```
+
+# To reproduce this issue, please run the QEMU process with the following command line.
+
+$ qemu-system-i386 -m 512  -drive file=hyfuzz.img,index=0,media=disk,format=raw -device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=4 -drive file=disk.img,if=none,id=drive0
+
+```
+
+Please let me know if I can provide any further info.
+
+Thank you.
+
+
+
+This is OSS-Fuzz Issue 26797
+
+=== Reproducer ===
+cat << EOF | ./qemu-system-i386 -machine q35 \
+-device virtio-blk,drive=disk0 \
+-drive file=null-co://,id=disk0,if=none,format=raw \
+-serial none -monitor none -qtest stdio -nographic 
+outl 0xcf8 0x80001890
+outl 0xcfc 0x4
+outl 0xcf8 0x8000188a
+outl 0xcfc 0xd4624
+outl 0xcf8 0x80001894
+outl 0xcfc 0x20000002
+outl 0xcf8 0x80001889
+outl 0xcfc 0x18000000
+outl 0xcf8 0x80001896
+outl 0xcfc 0x0
+outl 0xcf8 0x8000188c
+outw 0xcfc 0x20
+outl 0xcf8 0x80001894
+outl 0xcfc 0x1
+outl 0xcf8 0x8000188c
+outw 0xcfc 0x1c
+outl 0xcf8 0x80001895
+outl 0xcfc 0x0
+outl 0xcf8 0x80001889
+outl 0xcfc 0x18000000
+outl 0xcf8 0x80001894
+outl 0xcfc 0x40
+outl 0xcf8 0x8000188c
+outw 0xcfc 0x14
+outl 0xcf8 0x80001894
+outl 0xcfc 0x1004
+EOF
+
+=== Stack Trace ===
+qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.
+
+==2382430== ERROR: libFuzzer: deadly signal
+#8 address_space_stw_le_cached /src/qemu/include/exec/memory_ldst_cached.h.inc:88:5
+#9 stw_le_phys_cached /src/qemu/include/exec/memory_ldst_phys.h.inc:121:5
+#10 virtio_stw_phys_cached /src/qemu/include/hw/virtio/virtio-access.h:196:9
+#11 vring_set_avail_event /src/qemu/hw/virtio/virtio.c:429:5
+#12 virtio_queue_split_set_notification /src/qemu/hw/virtio/virtio.c:438:9
+#13 virtio_queue_set_notification /src/qemu/hw/virtio/virtio.c:499:9
+#14 virtio_blk_handle_vq /src/qemu/hw/block/virtio-blk.c:795:13
+#15 virtio_blk_data_plane_handle_output /src/qemu/hw/block/dataplane/virtio-blk.c:165:12
+#16 virtio_queue_notify_aio_vq /src/qemu/hw/virtio/virtio.c:2326:15
+#17 virtio_queue_host_notifier_aio_read /src/qemu/hw/virtio/virtio.c:3533:9
+#18 aio_dispatch_handler /src/qemu/util/aio-posix.c:329:9
+#19 aio_dispatch_handlers /src/qemu/util/aio-posix.c:372:20
+#20 aio_dispatch /src/qemu/util/aio-posix.c:382:5
+#21 aio_ctx_dispatch /src/qemu/util/async.c:306:5
+#22 g_main_context_dispatch
+#23 glib_pollfds_poll /src/qemu/util/main-loop.c:232:9
+#24 os_host_main_loop_wait /src/qemu/util/main-loop.c:255:5
+#25 main_loop_wait /src/qemu/util/main-loop.c:531:11
+#26 flush_events /src/qemu/tests/qtest/fuzz/fuzz.c:49:9
+#27 generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:683:17
+
+https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed.6797
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/301
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1911 b/results/classifier/zero-shot/118/peripherals/1911
new file mode 100644
index 00000000..53655f2e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1911
@@ -0,0 +1,70 @@
+peripherals: 0.909
+mistranslation: 0.901
+hypervisor: 0.879
+graphic: 0.848
+TCG: 0.841
+KVM: 0.836
+semantic: 0.791
+vnc: 0.787
+user-level: 0.786
+debug: 0.779
+permissions: 0.769
+ppc: 0.763
+VMM: 0.750
+assembly: 0.743
+device: 0.723
+arm: 0.721
+x86: 0.695
+architecture: 0.690
+register: 0.687
+performance: 0.672
+boot: 0.629
+virtual: 0.604
+risc-v: 0.601
+PID: 0.597
+socket: 0.523
+network: 0.512
+i386: 0.397
+kernel: 0.390
+files: 0.373
+
+abnormal segfaults inside qemu-system-riscv64
+Description of problem:
+3 tests of Cockatrice segfaults in qemu-system-riscv64 emulator. This is similar to a regression of qemu-riscv64-static I reported: #1908.
+But for qemu-system-riscv64, it doesn't looks like a recent regression because qemu 7.2.1 also fails.
+Steps to reproduce:
+To save the time on reproducing this bug, [I uploaded the zstd compressed qcow2 image to google drive](https://drive.google.com/file/d/1-2Wtmq4MlGvTLjmQ7P5vAvNlWg8--jjT/view?usp=sharing). It contains the whole environment, cockatrice source code and built tests.
+
+The password of the root user is `archriscv`.
+
+1. Setup Arch Linux riscv environment: https://github.com/CoelacanthusHex/archriscv-scriptlet https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-using-qemu-system
+2. Start it(with the commandline above, in the boot menu, choose `2:      Linux linux (fallback initramfs)`) and building cockatrice with tests in it. 
+3. Run tests (/root/Cockatrice/build/tests/loading_from_clipboard/loading_from_clipboard_test, /root/Cockatrice/build/tests/carddatabase/filter_string_test, /root/Cockatrice/build/tests/carddatabase/carddatabase_test)
+4. The tests segfault, which is unexpected.
+Additional information:
+The tests segfault at exactly the same instruction as in #1908:
+
+```
+┌──────────────────────────────────────────────────────────────────────────────┐
+│  > 0x7ffff2cba928  lhu     a2,1248(a2)                                       │
+│    0x7ffff2cba92c  and     a0,a0,127                                         │
+│    0x7ffff2cba930  sll     a2,a2,0x7                                         │
+│    0x7ffff2cba934  add     a0,a0,a2                                          │
+│    0x7ffff2cba938  lui     t2,0xf8000                                        │
+│    0x7ffff2cba93c  lui     a2,0xf5de2                                        │
+│    0x7ffff2cba940  add     a2,a2,-1824                                       │
+│    0x7ffff2cba944  sll     t2,t2,0x14                                        │
+│    0x7ffff2cba948  xor     a2,a2,t2                                          │
+│    0x7ffff2cba94c  sll     t2,a0,0x1                                         │
+│    0x7ffff2cba950  add     a2,a2,t2                                          │
+│    0x7ffff2cba954  lhu     a2,0(a2)                                          │
+│    0x7ffff2cba958  sll     a0,a2,0x3                                         │
+└──────────────────────────────────────────────────────────────────────────────┘
+multi-thre Thread 0x7ffff2cbe0 In:                     L??   PC: 0x7ffff2cba928
+(gdb) bt
+#0  0x00007ffff2cba928 in  ()
+```
+
+It might suggest that 2d708164e0475064e0e2167bd73e8570e22df1e0 is not the true cause of #1908 and this bug shares the same underlying cause with #1908.
+
+Commit 2d708164e0475064e0e2167bd73e8570e22df1e0 LGTM, although it seems that it is copied from the loongarch one and the author forgot to update [the file header](https://gitlab.com/qemu-project/qemu/-/blob/2d708164e0475064e0e2167bd73e8570e22df1e0/linux-user/riscv/target_mman.h#L1-6).
diff --git a/results/classifier/zero-shot/118/peripherals/1912780 b/results/classifier/zero-shot/118/peripherals/1912780
new file mode 100644
index 00000000..13d43efa
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1912780
@@ -0,0 +1,214 @@
+peripherals: 0.831
+hypervisor: 0.825
+x86: 0.808
+TCG: 0.804
+ppc: 0.801
+user-level: 0.800
+VMM: 0.796
+risc-v: 0.780
+vnc: 0.764
+KVM: 0.752
+register: 0.726
+performance: 0.713
+virtual: 0.711
+mistranslation: 0.707
+graphic: 0.697
+permissions: 0.686
+arm: 0.677
+debug: 0.663
+boot: 0.661
+device: 0.658
+semantic: 0.656
+architecture: 0.646
+assembly: 0.631
+PID: 0.615
+network: 0.610
+socket: 0.584
+files: 0.543
+kernel: 0.534
+i386: 0.518
+
+QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c
+
+[via qemu-security list]
+
+This is Gaoning Pan from Zhejiang University & Ant Security Light-Year Lab.
+I found a Null Pointer issue locates in fdctrl_read() in  hw/block/fdc.c.
+This flaw allows a malicious guest user or process in a denial of service condition.
+
+This issus was discovered in the latest Qemu-5.2.0. When using floppy device, there are several
+choices to get specific drive in get_drv(), depending on fdctrl->cur_drv. But not all drives are
+initialized properly, leaving fdctrl->drives[0]->blk as NULL. So when the drive was used in
+blk_pread(cur_drv->blk, fd_offset(cur_drv), fdctrl->fifo, BDRV_SECTOR_SIZE) at line 1918,
+null pointer access triggers, thus denial of service.My reproduced environment is as follows:
+
+    Host: ubuntu 18.04
+    Guest: ubuntu 18.04
+
+My boot command is as follows:
+
+  qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive format=qcow2,file=./ubuntu.img \
+   -nic user,hostfwd=tcp:0.0.0.0:5555-:22 -device floppy,unit=1,drive=mydrive \
+   -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none -display none
+
+ASAN output is as follows:
+=================================================================
+==14688==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000034c (pc 0x5636eee9bbaf bp 0x7ff2a53fdea0 sp 0x7ff2a53fde90 T3)
+==14688==The signal is caused by a WRITE memory access.
+==14688==Hint: address points to the zero page.
+    #0 0x5636eee9bbae in blk_inc_in_flight ../block/block-backend.c:1356
+    #1 0x5636eee9b766 in blk_prw ../block/block-backend.c:1328
+    #2 0x5636eee9cd76 in blk_pread ../block/block-backend.c:1491
+    #3 0x5636ee1adf24 in fdctrl_read_data ../hw/block/fdc.c:1918
+    #4 0x5636ee1a6654 in fdctrl_read ../hw/block/fdc.c:935
+    #5 0x5636eebb84c8 in portio_read ../softmmu/ioport.c:179
+    #6 0x5636ee9848c5 in memory_region_read_accessor ../softmmu/memory.c:442
+    #7 0x5636ee9855c2 in access_with_adjusted_size ../softmmu/memory.c:552
+    #8 0x5636ee98f0b7 in memory_region_dispatch_read1 ../softmmu/memory.c:1420
+    #9 0x5636ee98f311 in memory_region_dispatch_read ../softmmu/memory.c:1449
+    #10 0x5636ee8ff64a in flatview_read_continue ../softmmu/physmem.c:2822
+    #11 0x5636ee8ff9e5 in flatview_read ../softmmu/physmem.c:2862
+    #12 0x5636ee8ffb83 in address_space_read_full ../softmmu/physmem.c:2875
+    #13 0x5636ee8ffdeb in address_space_rw ../softmmu/physmem.c:2903
+    #14 0x5636eea6a924 in kvm_handle_io ../accel/kvm/kvm-all.c:2285
+    #15 0x5636eea6c5e3 in kvm_cpu_exec ../accel/kvm/kvm-all.c:2531
+    #16 0x5636eeca492b in kvm_vcpu_thread_fn ../accel/kvm/kvm-cpus.c:49
+    #17 0x5636ef1bc296 in qemu_thread_start ../util/qemu-thread-posix.c:521
+    #18 0x7ff337c736da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
+    #19 0x7ff33799ca3e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x121a3e)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV ../block/block-backend.c:1356 in blk_inc_in_flight
+Thread T3 created by T0 here:
+    #0 0x7ff33c580d2f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37d2f)
+    #1 0x5636ef1bc673 in qemu_thread_create ../util/qemu-thread-posix.c:558
+    #2 0x5636eeca4ce7 in kvm_start_vcpu_thread ../accel/kvm/kvm-cpus.c:73
+    #3 0x5636ee9aa965 in qemu_init_vcpu ../softmmu/cpus.c:622
+    #4 0x5636ee82a9b4 in x86_cpu_realizefn ../target/i386/cpu.c:6731
+    #5 0x5636eed002f4 in device_set_realized ../hw/core/qdev.c:886
+    #6 0x5636eecc59bc in property_set_bool ../qom/object.c:2251
+    #7 0x5636eecc0c28 in object_property_set ../qom/object.c:1398
+    #8 0x5636eecb6fb9 in object_property_set_qobject ../qom/qom-qobject.c:28
+    #9 0x5636eecc1175 in object_property_set_bool ../qom/object.c:1465
+    #10 0x5636eecfc286 in qdev_realize ../hw/core/qdev.c:399
+    #11 0x5636ee739b34 in x86_cpu_new ../hw/i386/x86.c:111
+    #12 0x5636ee739d6d in x86_cpus_init ../hw/i386/x86.c:138
+    #13 0x5636ee6f843e in pc_init1 ../hw/i386/pc_piix.c:159
+    #14 0x5636ee6fab1e in pc_init_v5_2 ../hw/i386/pc_piix.c:438
+    #15 0x5636ee1cb4a7 in machine_run_board_init ../hw/core/machine.c:1134
+    #16 0x5636ee9c323d in qemu_init ../softmmu/vl.c:4369
+    #17 0x5636edd92c71 in main ../softmmu/main.c:49
+    #18 0x7ff33789cb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
+
+==14688==ABORTING
+
+Reproducer is attached.
+
+Best regards.
+Gaoning Pan of Zhejiang University & Ant Security Light-Year Lab
+
+
+
+The given reproducer does not seem to work as expected to trigger this issue.
+IIUC, issue occurs because a privileged guest user may change the selected
+floppy drive via FD_REG_DOR:fdctrl_write_dor() ioport write command
+
+  static void fdctrl_write_dor(FDCtrl *fdctrl, uint32_t value)                    
+  {
+      ...
+      /* Selected drive */ 
+      fdctrl->cur_drv = value & FD_DOR_SELMASK;  <= selected drive changes based on 'value'
+      ...
+  }
+
+Little tweaking of parameters under gdb reproduces the crash
+
+$ gdb --args ./bin/qemu-system-x86_64 -runas test -nographic -enable-kvm -m 2048
+   -drive file=fdc.img,format=qcow2,if=floppy,id=myfdc /var/lib/libvirt/images/f27vm.qcow2
+...
+==541702==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000034c (pc 0x55555938377f bp 0x7fff6f3fdeb0 sp 0x7fff6f3fdea0 T3)
+==541702==The signal is caused by a WRITE memory access.
+==541702==Hint: address points to the zero page.
+    #0 0x55555938377f in blk_inc_in_flight ../block/block-backend.c:1356
+    #1 0x55555938325b in blk_prw ../block/block-backend.c:1328
+    #2 0x555559384ec5 in blk_pread ../block/block-backend.c:1491
+    #3 0x555557d7c798 in fdctrl_read_data ../hw/block/fdc.c:1919
+    #4 0x555557d7207c in fdctrl_read ../hw/block/fdc.c:936
+    #5 0x555558ee7c40 in portio_read ../softmmu/ioport.c:179
+    #6 0x555558c9a0c1 in memory_region_read_accessor ../softmmu/memory.c:442
+    #7 0x555558c9af04 in access_with_adjusted_size ../softmmu/memory.c:552
+    #8 0x555558ca7159 in memory_region_dispatch_read1 ../softmmu/memory.c:1420
+    #9 0x555558ca7433 in memory_region_dispatch_read ../softmmu/memory.c:1449
+    #10 0x555558f6214e in flatview_read_continue ../softmmu/physmem.c:2822
+    #11 0x555558f62560 in flatview_read ../softmmu/physmem.c:2862
+    #12 0x555558f62700 in address_space_read_full ../softmmu/physmem.c:2875
+    #13 0x555558f62977 in address_space_rw ../softmmu/physmem.c:2903
+    #14 0x555558d037b9 in kvm_handle_io ../accel/kvm/kvm-all.c:2285
+    #15 0x555558d05a4b in kvm_cpu_exec ../accel/kvm/kvm-all.c:2531
+    #16 0x555558ee0efa in kvm_vcpu_thread_fn ../accel/kvm/kvm-cpus.c:49
+    #17 0x55555977ec18 in qemu_thread_start ../util/qemu-thread-posix.c:521
+    #18 0x7ffff63323f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
+    #19 0x7ffff625f902 in __GI___clone (/lib64/libc.so.6+0x101902)
+
+Proposed patch:
+
+$ git diff hw/block/
+diff --git a/hw/block/fdc.c b/hw/block/fdc.c
+index 3636874432..13a9470d19 100644
+--- a/hw/block/fdc.c
++++ b/hw/block/fdc.c
+@@ -1429,7 +1429,9 @@ static void fdctrl_write_dor(FDCtrl *fdctrl, uint32_t value)
+         }
+     }
+     /* Selected drive */
+-    fdctrl->cur_drv = value & FD_DOR_SELMASK;
++    if (fdctrl->drives[value & FD_DOR_SELMASK].blk) {
++        fdctrl->cur_drv = value & FD_DOR_SELMASK;
++    }
+ 
+     fdctrl->dor = value;
+ }
+@@ -1894,6 +1896,10 @@ static uint32_t fdctrl_read_data(FDCtrl *fdctrl)
+     uint32_t pos;
+ 
+     cur_drv = get_cur_drv(fdctrl);
++    if (!cur_drv->blk) {
++        FLOPPY_DPRINTF("No drive connected\n");
++        return 0;
++    }
+     fdctrl->dsr &= ~FD_DSR_PWRDOWN;
+     if (!(fdctrl->msr & FD_MSR_RQM) || !(fdctrl->msr & FD_MSR_DIO)) {
+         FLOPPY_DPRINTF("error: controller not ready for reading\n");
+@@ -2420,7 +2426,8 @@ static void fdctrl_write_data(FDCtrl *fdctrl, uint32_t value)
+         if (pos == FD_SECTOR_LEN - 1 ||
+             fdctrl->data_pos == fdctrl->data_len) {
+             cur_drv = get_cur_drv(fdctrl);
+-            if (blk_pwrite(cur_drv->blk, fd_offset(cur_drv), fdctrl->fifo,
++            if (cur_drv->blk == NULL
++                || blk_pwrite(cur_drv->blk, fd_offset(cur_drv), fdctrl->fifo,
+                            BDRV_SECTOR_SIZE, 0) < 0) {
+                 FLOPPY_DPRINTF("error writing sector %d\n",
+                                fd_sector(cur_drv));
+
+On Friday, 22 January, 2021, 05:42:55 pm IST, 潘高宁 <email address hidden> wrote: 
+>  This patch seems to work now. I've re-compiled and tested the QEMU, which showed the functional operation was working well.
+
+
+CVE-2021-20196 assigned by Red Hat Inc.
+
+
+Upstream patch:
+  -> https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg05986.html
+
+Took a look at the patch today, I think it might need a change or two but it should be quick to do. I've asked Thomas to move this issue to gitlab so I can keep a closer eye on it.
+
+--js
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/338
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1913344 b/results/classifier/zero-shot/118/peripherals/1913344
new file mode 100644
index 00000000..93f0b4f6
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1913344
@@ -0,0 +1,43 @@
+peripherals: 0.993
+device: 0.907
+mistranslation: 0.852
+architecture: 0.833
+vnc: 0.794
+network: 0.792
+kernel: 0.775
+socket: 0.758
+ppc: 0.750
+performance: 0.750
+register: 0.748
+semantic: 0.700
+risc-v: 0.682
+x86: 0.654
+arm: 0.631
+PID: 0.609
+VMM: 0.607
+graphic: 0.575
+permissions: 0.564
+i386: 0.552
+boot: 0.538
+files: 0.524
+TCG: 0.504
+debug: 0.490
+KVM: 0.425
+user-level: 0.369
+hypervisor: 0.363
+virtual: 0.281
+assembly: 0.248
+
+ Exynos4210 UART peripheral data loss
+
+Currently the Exynos4210 UART (hw/char/exynos4210_uart.c) incorrectly reports however many empty bytes are available in the FIFO when queried for receive capacity. However this peripheral supports a polled mode where only a single byte can be submitted at a time and the FIFO is unused, meaning that in polled mode data is lost since it's written into the FIFO and the polling code in FIFO disabled mode only returns the value in the RX data register.
+
+Even worse, potentially enabling the FIFO without a FIFO reset will create a weird situation where data is already in the FIFO whenever data came in faster than the polling could pick it up (which is basically always).
+
+This change obscured the issue in https://bugs.launchpad.net/qemu/+bug/1913341, which instead presented as strange data loss until I locally resolved this issue. 
+
+I have a patch ready for the bug and will submit it later today, I'm just filing for clarity.
+
+commit 40b4c2ae90e4f864a1015ff748a4af00518ff0c0
+
+
diff --git a/results/classifier/zero-shot/118/peripherals/1916655 b/results/classifier/zero-shot/118/peripherals/1916655
new file mode 100644
index 00000000..55f23264
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1916655
@@ -0,0 +1,85 @@
+peripherals: 0.955
+kernel: 0.919
+debug: 0.900
+hypervisor: 0.891
+graphic: 0.887
+architecture: 0.880
+semantic: 0.877
+permissions: 0.861
+device: 0.858
+x86: 0.836
+files: 0.835
+mistranslation: 0.820
+arm: 0.817
+PID: 0.805
+vnc: 0.796
+network: 0.778
+user-level: 0.772
+ppc: 0.762
+VMM: 0.754
+socket: 0.752
+virtual: 0.750
+KVM: 0.726
+assembly: 0.711
+performance: 0.703
+i386: 0.701
+register: 0.700
+risc-v: 0.661
+TCG: 0.609
+boot: 0.535
+
+Compilation fails due to zstd qcow2 compression
+
+Compilation of QEMU fails when using recent versions of zstd.
+
+I use the following commands to compile QEMU:
+$ mkdir build
+$ cd build
+$ ../configure --enable-debug --target-list=x86_64-softmmu
+$ make -j $(nproc)
+
+Here is a paste from the ../configure output:
+https://paste.ubuntu.com/p/dHsWzGV7TH/
+
+And one from the make output:
+https://paste.ubuntu.com/p/89qKk4NrFz/
+
+In short the error boils down to:
+../block/qcow2-threads.c: In function ‘qcow2_zstd_compress’:
+../block/qcow2-threads.c:225:16: error: implicit declaration of function ‘ZSTD_compressStream2’; did you mean ‘ZSTD_compressStream’? [-Werror=implicit-function-declaration]
+  225 |     zstd_ret = ZSTD_compressStream2(cctx, &output, &input, ZSTD_e_end);
+      |                ^~~~~~~~~~~~~~~~~~~~
+      |                ZSTD_compressStream
+../block/qcow2-threads.c:225:16: error: nested extern declaration of ‘ZSTD_compressStream2’ [-Werror=nested-externs]
+../block/qcow2-threads.c:225:60: error: ‘ZSTD_e_end’ undeclared (first use in this function)
+  225 |     zstd_ret = ZSTD_compressStream2(cctx, &output, &input, ZSTD_e_end);
+      |
+
+System info:
+QEMU commit: 7ef8134565dccf9186d5eabd7dbb4ecae6dead87 (from Github)
+Kernel: 5.10.15
+zstd: 1.4.8
+
+The upstream zstd library seems to still offer that function as of 1.4.9:
+
+https://github.com/facebook/zstd/blob/dev/lib/zstd.h#L708
+
+what exact version of the zstd package do you have installed (Is it an Ubuntu package, a Fedora one? etc) 
+
+Can you verify that the version of the header you have installed for zstd.h actually declares ZSTD_compressStream2() ?
+
+
+Seems I had an old version (1.3.5) of zstd floating around in /usr/local. Consider this issue resolved.
+
+Meson theoretically checks for that:
+
+meson.build:  zstd = dependency('libzstd', version: '>=1.4.0',
+
+I suppose meson found the dependency, but the compile flags got the wrong header. Is there something we need to fix in the build system?
+
+> Is there something we need to fix in the build system?
+
+Maybe, I do not know how this dependency is validated. If the directories used to validate dependencies differs from the directories (or order) used at compile / link time than this can cause errors like these.
+
+However, what could also happen I suppose that the order in which headers are included differs from the order in which libraries are included. This could still be caused by the build system but also by the user (LD_PRELOAD, ld-config etc).
+
diff --git a/results/classifier/zero-shot/118/peripherals/1917085 b/results/classifier/zero-shot/118/peripherals/1917085
new file mode 100644
index 00000000..e6724e97
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1917085
@@ -0,0 +1,97 @@
+peripherals: 0.889
+user-level: 0.866
+mistranslation: 0.821
+hypervisor: 0.797
+register: 0.796
+x86: 0.778
+risc-v: 0.761
+KVM: 0.741
+performance: 0.738
+arm: 0.737
+permissions: 0.733
+device: 0.733
+graphic: 0.732
+vnc: 0.732
+TCG: 0.727
+ppc: 0.720
+semantic: 0.716
+VMM: 0.711
+socket: 0.710
+debug: 0.705
+i386: 0.701
+network: 0.700
+files: 0.696
+virtual: 0.696
+PID: 0.678
+assembly: 0.675
+boot: 0.675
+architecture: 0.651
+kernel: 0.629
+
+ [OSS-Fuzz] Issue 30588 pcnet: Loopback-related stack-overflow
+
+=== Reproducer ===
+cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \
+512M -machine q35 -nodefaults -device pcnet,netdev=net0 -netdev \
+user,id=net0 -qtest /dev/null -qtest stdio
+outl 0xcf8 0x80000810
+outl 0xcfc 0xc001
+outl 0xcf8 0x80000804
+outw 0xcfc 0x7
+outl 0xc011 0xff14ff
+outl 0xcf8 0x80000815
+outl 0xcfc 0xffffffff
+outl 0xc015 0x35a
+inl 0xc012
+outw 0xc010 0x6165
+outw 0xc010 0x1127
+write 0x0 0x1 0x56
+write 0x2 0x1 0xff
+write 0x15 0x1 0xff
+write 0x16 0x1 0xff
+write 0x17 0x1 0xff
+write 0x18 0x1 0xfd
+write 0x19 0x1 0x59
+write 0x1a 0x1 0xfe
+write 0x1b 0x1 0xff
+outw 0xc010 0x1db
+EOF
+
+=== Stack-trace ===
+==312573==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd5bb4cec8 (pc 0x55a8f1c9cf36 bp 0x7ffd5bb4d710 sp 0x7ffd5bb4ced0 T0)
+#0 0x55a8f1c9cf36 in __asan_memcpy (/home/alxndr/Development/qemu/build/qemu-system-i386+0x2baff36)
+#1 0x55a8f2f54ddf in flatview_do_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:518:12
+#2 0x55a8f2f6ec8e in flatview_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:568:15
+#3 0x55a8f2f6ec8e in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2878:10
+#4 0x55a8f2f6ec8e in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18
+#5 0x55a8f273036e in pcnet_rmd_load /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:381:9
+#6 0x55a8f272e386 in pcnet_rdte_poll /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:896:9
+#7 0x55a8f27299d0 in pcnet_receive /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1016:9
+#8 0x55a8f27406be in pcnet_transmit /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1253:13
+#9 0x55a8f2735b4c in pcnet_poll_timer /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1322:9
+#10 0x55a8f273c353 in pcnet_ioport_readl /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1660:5
+#11 0x55a8f2727361 in pcnet_ioport_read /home/alxndr/Development/qemu/build/../hw/net/pcnet-pci.c:107:20
+#12 0x55a8f309e9f6 in memory_region_read_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:442:11
+#13 0x55a8f3070d63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18
+#14 0x55a8f306f222 in memory_region_dispatch_read1 /home/alxndr/Development/qemu/build/../softmmu/memory.c
+#15 0x55a8f306f222 in memory_region_dispatch_read /home/alxndr/Development/qemu/build/../softmmu/memory.c:1449:9
+#16 0x55a8f2f6d88f in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2839:23
+#17 0x55a8f2f6ed1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12
+#18 0x55a8f2f6ed1b in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18
+#19 0x55a8f273036e in pcnet_rmd_load /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:381:9
+#20 0x55a8f2729d97 in pcnet_receive /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1028:17
+#21 0x55a8f27406be in pcnet_transmit /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1253:13
+#22 0x55a8f2735b4c in pcnet_poll_timer /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1322:9
+#23 0x55a8f273c353 in pcnet_ioport_readl /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1660:5
+#24 0x55a8f2727361 in pcnet_ioport_read /home/alxndr/Development/qemu/build/../hw/net/pcnet-pci.c:107:20
+#25 0x55a8f309e9f6 in memory_region_read_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:442:11
+#26 0x55a8f3070d63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18
+#27 0x55a8f306f222 in memory_region_dispatch_read1 /home/alxndr/Development/qemu/build/../softmmu/memory.c
+#28 0x55a8f306f222 in memory_region_dispatch_read /home/alxndr/Development/qemu/build/../softmmu/memory.c:1449:9
+#29 0x55a8f2f6d88f in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2839:23
+#30 0x55a8f2f6ed1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12
+
+OSS-Fuzz says this has been fixed
+
+https://gitlab.com/qemu-project/qemu/-/commit/99ccfaa1edafd79f7a3a0ff7
+
diff --git a/results/classifier/zero-shot/118/peripherals/193 b/results/classifier/zero-shot/118/peripherals/193
new file mode 100644
index 00000000..87ac1e60
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/193
@@ -0,0 +1,31 @@
+peripherals: 0.979
+device: 0.931
+performance: 0.901
+network: 0.810
+PID: 0.798
+graphic: 0.774
+arm: 0.520
+debug: 0.483
+boot: 0.319
+architecture: 0.279
+ppc: 0.140
+permissions: 0.106
+mistranslation: 0.099
+risc-v: 0.093
+semantic: 0.089
+user-level: 0.087
+virtual: 0.071
+hypervisor: 0.064
+register: 0.056
+files: 0.055
+VMM: 0.036
+assembly: 0.028
+socket: 0.021
+vnc: 0.017
+TCG: 0.015
+i386: 0.007
+kernel: 0.004
+x86: 0.002
+KVM: 0.001
+
+piix crashes on mips when using multiple cpus
diff --git a/results/classifier/zero-shot/118/peripherals/1970563 b/results/classifier/zero-shot/118/peripherals/1970563
new file mode 100644
index 00000000..940fe966
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1970563
@@ -0,0 +1,149 @@
+peripherals: 0.942
+permissions: 0.925
+ppc: 0.896
+hypervisor: 0.886
+VMM: 0.886
+mistranslation: 0.877
+semantic: 0.870
+vnc: 0.868
+user-level: 0.865
+register: 0.857
+risc-v: 0.840
+assembly: 0.839
+socket: 0.824
+virtual: 0.817
+graphic: 0.810
+architecture: 0.801
+arm: 0.795
+PID: 0.786
+KVM: 0.757
+TCG: 0.747
+performance: 0.745
+network: 0.743
+device: 0.741
+x86: 0.709
+files: 0.686
+debug: 0.670
+kernel: 0.632
+boot: 0.613
+i386: 0.294
+
+Qemu 1:6.2+dfsg-2ubuntu6 deadlock bug
+
+There is a known bug that will cause VM deadlock, the patch should be merged and released:
+
+https://gitlab.com/qemu-project/qemu/-/commit/1dbbe6f172810026c51dc84ed927a3cc23017949#841723aa93098d8ab3b5068795e10ae7cf2a3179
+
+That's clearly a fix for a bug, but I couldn't identify an upstream issue which describes the problem. The commit message has:
+
+  Fixes: 0bf41cab
+
+but that's a reference to another commit, not to an issue. Finding original description of the bug would help identifying a test case for the SRU.
+
+@xp are you able to point us to the upstream bug report, or to provide steps to reproduce the issue which we can use to verify the fix?
+
+I'm marking this as Incomplete for now because the description of the problem is too vague, but I think this will become a valid SRU case.
+
+This should be the upstream bug report:
+https://gitlab.com/qemu-project/qemu/-/issues/807
+
+
+Thanks, that report also has nice steps to reproduce. I updated the bug tags/status accordingly.
+
+Thanks
+
+From the description this bug affects Jammy and Kinetic, so I added explicit tasks for each series.
+
+Thanks this is great pre-work and a patch on a plate.
+I was pondering if I should wait until we merge qemu 7.0 for kintic, but that would delay this too much.
+
+I still need to find some time, but I'll prepare and upload the fix without waiting for 7.0.
+
+FYI - I have prepared a PPA and merge proposals for the related Ubuntu package changes:
+
+PPA: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1970563-vnc-deadlock
+Jammy: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/422947
+Kinetic: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/422946
+
+Thanks for the Review Sergio.
+
+Uploaded the fix for Kinetic.
+We can start the SRU to jammy once it is complete there.
+
+This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu7
+
+---------------
+qemu (1:6.2+dfsg-2ubuntu7) kinetic; urgency=medium
+
+  * d/p/u/lp-1970563-ui-vnc.c-Fixed-a-deadlock-bug.patch: avoid deadlock
+    in vnc connections (LP: #1970563)
+
+ -- Christian Ehrhardt <email address hidden>  Thu, 19 May 2022 08:25:20 +0200
+
+Completed in Kinetic, uploaded to Jammy now - waiting for the SRU team to have a look
+
+Hello xp, or anyone else affected,
+
+Accepted qemu into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:6.2+dfsg-2ubuntu6.1 in a few hours, and then in the -proposed repository.
+
+Please help us by testing this new package.  See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.  Your feedback will aid us getting this update out to other Ubuntu users.
+
+If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.
+
+Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in advance for helping!
+
+N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.
+
+All autopkgtests for the newly accepted qemu (1:6.2+dfsg-2ubuntu6.1) for jammy have finished running.
+The following regressions have been reported in tests triggered by the package:
+
+vagrant-mutate/1.2.0-4.1 (s390x, ppc64el)
+livecd-rootfs/2.764 (arm64, ppc64el)
+ubuntu-image/2.2+22.04ubuntu3 (arm64, s390x)
+sbuild/0.81.2ubuntu6 (s390x, ppc64el)
+edk2/2022.02-3 (armhf)
+initramfs-tools/0.140ubuntu13 (amd64)
+systemd/249.11-0ubuntu3.1 (ppc64el)
+
+
+Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].
+
+https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#qemu
+
+[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
+
+Thank you!
+
+
+FYI: Autopkgtest issues resolved, but verification of the upload for the presented problem is needed.
+
+@XP - it is always best to do this in the original reported environment - do you think you could do that verification?
+
+Sure, This my test steps:
+* start a qemu wit qemu vnc
+   qemu-system-x86_64 -vnc 127.0.0.1:0 ...
+
+* Connect and disconnect and connect with VNC against it (We use novnc).
+
+* when qemu-system-x86 1:6.2+dfsg-2ubuntu6
+	occur which deadlocks qemu - no interaction is possible anymore
+
+* upgrade to qemu-system-x86/jammy-proposed 1:6.2+dfsg-2ubuntu6.1
+    Connect and disconnect and connect, everything is ok， no more deadlock
+
+The bug has been fixed, thank you.
+
+Perfect, thank you Xiongpeng!
+
+The verification of the Stable Release Update for qemu has completed successfully and the package is now being released to -updates.  Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report.  In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
+
+This bug was fixed in the package qemu - 1:6.2+dfsg-2ubuntu6.1
+
+---------------
+qemu (1:6.2+dfsg-2ubuntu6.1) jammy; urgency=medium
+
+  * d/p/u/lp-1970563-ui-vnc.c-Fixed-a-deadlock-bug.patch: avoid deadlock
+    in vnc connections (LP: #1970563)
+
+ -- Christian Ehrhardt <email address hidden>  Thu, 19 May 2022 08:25:20 +0200
+
diff --git a/results/classifier/zero-shot/118/peripherals/198 b/results/classifier/zero-shot/118/peripherals/198
new file mode 100644
index 00000000..651baeba
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/198
@@ -0,0 +1,31 @@
+peripherals: 0.932
+network: 0.930
+device: 0.906
+performance: 0.753
+graphic: 0.448
+semantic: 0.366
+mistranslation: 0.365
+architecture: 0.274
+arm: 0.252
+debug: 0.252
+boot: 0.208
+permissions: 0.168
+ppc: 0.156
+x86: 0.127
+kernel: 0.107
+KVM: 0.096
+user-level: 0.092
+register: 0.084
+i386: 0.082
+vnc: 0.051
+PID: 0.044
+files: 0.038
+hypervisor: 0.031
+virtual: 0.027
+assembly: 0.027
+socket: 0.023
+TCG: 0.017
+VMM: 0.017
+risc-v: 0.016
+
+USB Ethernet device (RNDIS) does not work on several tested operating systems
diff --git a/results/classifier/zero-shot/118/peripherals/1982 b/results/classifier/zero-shot/118/peripherals/1982
new file mode 100644
index 00000000..31edb726
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/1982
@@ -0,0 +1,39 @@
+peripherals: 0.975
+mistranslation: 0.935
+graphic: 0.891
+boot: 0.840
+device: 0.793
+ppc: 0.680
+socket: 0.680
+semantic: 0.666
+files: 0.597
+network: 0.538
+performance: 0.492
+vnc: 0.491
+register: 0.452
+architecture: 0.433
+debug: 0.423
+arm: 0.419
+risc-v: 0.379
+kernel: 0.365
+PID: 0.326
+permissions: 0.281
+i386: 0.246
+VMM: 0.195
+TCG: 0.173
+hypervisor: 0.160
+x86: 0.157
+user-level: 0.120
+assembly: 0.094
+KVM: 0.058
+virtual: 0.054
+
+PS/2 mouse and keyboard not disabled when adding USB devices
+Description of problem:
+Documentation (such as https://www.qemu.org/docs/master/system/qemu-manpage.html or https://www.qemu.org/docs/master/system/devices/usb.html) says that enabling a USB keyboard or mouse (or tablet) will disable the PS/2 equivalent, but it seems both are present instead.
+Steps to reproduce:
+1. Pass a `-usbdevice` or `-device` option to QEMU.
+2. Boot Haiku.
+3. Find two identical devices in Preferences > Input, both `Extended PS/2 Mouse 1` and `USB Tablet 1`, as well as `AT Keyboard 1` and `USB Keyboard 1`.
+Additional information:
+The content of /var/log/syslog, which shows discovery of PS/2 devices: [syslog.zst](/uploads/7ed067538c94edfdbaf35ec92a422c68/syslog.zst)
diff --git a/results/classifier/zero-shot/118/peripherals/2027 b/results/classifier/zero-shot/118/peripherals/2027
new file mode 100644
index 00000000..f62acf1f
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2027
@@ -0,0 +1,263 @@
+peripherals: 0.807
+risc-v: 0.787
+register: 0.761
+virtual: 0.737
+device: 0.737
+user-level: 0.731
+performance: 0.730
+debug: 0.723
+architecture: 0.715
+x86: 0.715
+arm: 0.712
+socket: 0.701
+VMM: 0.701
+network: 0.688
+graphic: 0.677
+boot: 0.674
+TCG: 0.672
+PID: 0.671
+vnc: 0.670
+semantic: 0.664
+KVM: 0.661
+ppc: 0.660
+hypervisor: 0.653
+assembly: 0.651
+permissions: 0.646
+i386: 0.614
+kernel: 0.604
+files: 0.578
+mistranslation: 0.494
+
+Go runtime panic with qemu-x86_64-static on aarch64 (bisected)
+Description of problem:
+I have run into some crashes with certain x86 Go binaries running on arm64 (Asahi Linux) using qemu-user-static. The issue is also reproducible on current master (9c74490bff6c8886a922008d0c9ce6cae70dd17e). I have bisected the issue to commit 2d708164e0475064e0e2167bd73e8570e22df1e0:
+
+```
+first bad commit: [2d708164e0475064e0e2167bd73e8570e22df1e0] linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h
+```
+Steps to reproduce:
+1. Build example Go program `GOARCH=amd64 go build -o crashing .`
+2. Run it with `qemu-x86_64-static ./crashing`
+
+<details><summary>Go program to reproduce</summary>
+
+```go
+package main
+
+import "crypto/x509"
+
+func main() {
+  x509.SystemCertPool()
+}
+```
+
+</details>
+Additional information:
+<details><summary>Go program stacktrace</summary>
+
+```
+runtime: lfstack.push invalid packing: node=0xffff3c3a9780 cnt=0x1 packed=0xffff3c3a97800001 -> node=0xffffffff3c3a9780
+fatal error: lfstack.push
+
+runtime stack:
+runtime.throw({0x52cb61?, 0x2ce5?})
+	/usr/lib/golang/src/runtime/panic.go:1077 +0x5c fp=0xc000613f08 sp=0xc000613ed8 pc=0x433d5c
+runtime.(*lfstack).push(0xa0000000002?, 0xffffffffffffefe8?)
+	/usr/lib/golang/src/runtime/lfstack.go:29 +0x125 fp=0xc000613f48 sp=0xc000613f08 pc=0x40ac25
+runtime.(*spanSetBlockAlloc).free(...)
+	/usr/lib/golang/src/runtime/mspanset.go:322
+runtime.(*spanSet).reset(0x64d220)
+	/usr/lib/golang/src/runtime/mspanset.go:264 +0x79 fp=0xc000613f78 sp=0xc000613f48 pc=0x42ef79
+runtime.finishsweep_m()
+	/usr/lib/golang/src/runtime/mgcsweep.go:260 +0x95 fp=0xc000613fb8 sp=0xc000613f78 pc=0x423455
+runtime.gcStart.func2()
+	/usr/lib/golang/src/runtime/mgc.go:687 +0xf fp=0xc000613fc8 sp=0xc000613fb8 pc=0x45bd8f
+traceback: unexpected SPWRITE function runtime.systemstack
+runtime.systemstack()
+	/usr/lib/golang/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000613fd8 sp=0xc000613fc8 pc=0x46016a
+
+goroutine 1 [running]:
+runtime.systemstack_switch()
+	/usr/lib/golang/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0001bb9f0 sp=0xc0001bb9e0 pc=0x460108
+runtime.gcStart({0xc000600000?, 0x98370?, 0x307800?})
+	/usr/lib/golang/src/runtime/mgc.go:686 +0x2e5 fp=0xc0001bba88 sp=0xc0001bb9f0 pc=0x418e05
+runtime.mallocgc(0x98370, 0x50bb80, 0x1)
+	/usr/lib/golang/src/runtime/malloc.go:1242 +0x76f fp=0xc0001bbaf0 sp=0xc0001bba88 pc=0x40caaf
+runtime.makeslice(0xc0001840a8?, 0x26?, 0x0?)
+	/usr/lib/golang/src/runtime/slice.go:103 +0x49 fp=0xc0001bbb18 sp=0xc0001bbaf0 pc=0x449729
+os.ReadFile({0xc00035a0f0?, 0x52dcd6?})
+	/usr/lib/golang/src/os/file.go:738 +0xe5 fp=0xc0001bbbf0 sp=0xc0001bbb18 pc=0x49ed25
+crypto/x509.loadSystemRoots()
+	/usr/lib/golang/src/crypto/x509/root_unix.go:70 +0x3d4 fp=0xc0001bbcd8 sp=0xc0001bbbf0 pc=0x4fdef4
+crypto/x509.initSystemRoots()
+	/usr/lib/golang/src/crypto/x509/root.go:30 +0x5c fp=0xc0001bbd10 sp=0xc0001bbcd8 pc=0x4fd9fc
+sync.(*Once).doSlow(0x1?, 0xb30000c00018ada0?)
+	/usr/lib/golang/src/sync/once.go:74 +0xbf fp=0xc0001bbd70 sp=0xc0001bbd10 pc=0x467bff
+sync.(*Once).Do(...)
+	/usr/lib/golang/src/sync/once.go:65
+crypto/x509.systemRootsPool()
+	/usr/lib/golang/src/crypto/x509/root.go:21 +0x45 fp=0xc0001bbdc0 sp=0xc0001bbd70 pc=0x4fd8a5
+crypto/x509.SystemCertPool()
+	/usr/lib/golang/src/crypto/x509/cert_pool.go:112 +0x25 fp=0xc0001bbf30 sp=0xc0001bbdc0 pc=0x4f6705
+main.main()
+	/home/cyrill/dev/goruntime-crash/main.go:6 +0xf fp=0xc0001bbf40 sp=0xc0001bbf30 pc=0x4ff18f
+runtime.main()
+	/usr/lib/golang/src/runtime/proc.go:267 +0x2bb fp=0xc0001bbfe0 sp=0xc0001bbf40 pc=0x43673b
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0001bbfe8 sp=0xc0001bbfe0 pc=0x461f61
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004efa8 sp=0xc00004ef88 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.forcegchelper()
+	/usr/lib/golang/src/runtime/proc.go:322 +0xb3 fp=0xc00004efe0 sp=0xc00004efa8 pc=0x436a13
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004efe8 sp=0xc00004efe0 pc=0x461f61
+created by runtime.init.6 in goroutine 1
+	/usr/lib/golang/src/runtime/proc.go:310 +0x1a
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004f778 sp=0xc00004f758 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.bgsweep(0x0?)
+	/usr/lib/golang/src/runtime/mgcsweep.go:321 +0xdf fp=0xc00004f7c8 sp=0xc00004f778 pc=0x4235bf
+runtime.gcenable.func1()
+	/usr/lib/golang/src/runtime/mgc.go:200 +0x25 fp=0xc00004f7e0 sp=0xc00004f7c8 pc=0x418945
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004f7e8 sp=0xc00004f7e0 pc=0x461f61
+created by runtime.gcenable in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:200 +0x66
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc00006c000?, 0x570658?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004ff70 sp=0xc00004ff50 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.(*scavengerState).park(0x625680)
+	/usr/lib/golang/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc00004ffa0 sp=0xc00004ff70 pc=0x420e49
+runtime.bgscavenge(0x0?)
+	/usr/lib/golang/src/runtime/mgcscavenge.go:658 +0x59 fp=0xc00004ffc8 sp=0xc00004ffa0 pc=0x4213f9
+runtime.gcenable.func2()
+	/usr/lib/golang/src/runtime/mgc.go:201 +0x25 fp=0xc00004ffe0 sp=0xc00004ffc8 pc=0x4188e5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x461f61
+created by runtime.gcenable in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:201 +0xa5
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x400000?, 0x10004e670?, 0x0?, 0x0?, 0x654640?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004e628 sp=0xc00004e608 pc=0x436b8e
+runtime.runfinq()
+	/usr/lib/golang/src/runtime/mfinal.go:193 +0x107 fp=0xc00004e7e0 sp=0xc00004e628 pc=0x4179c7
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004e7e8 sp=0xc00004e7e0 pc=0x461f61
+created by runtime.createfing in goroutine 1
+	/usr/lib/golang/src/runtime/mfinal.go:163 +0x3d
+
+goroutine 18 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004a750 sp=0xc00004a730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004a7e0 sp=0xc00004a750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004a7e8 sp=0xc00004a7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 19 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004af50 sp=0xc00004af30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004afe0 sp=0xc00004af50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 33 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090750 sp=0xc000090730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc0000907e0 sp=0xc000090750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0000907e8 sp=0xc0000907e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 20 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004b750 sp=0xc00004b730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004b7e0 sp=0xc00004b750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004b7e8 sp=0xc00004b7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 49 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00008c750 sp=0xc00008c730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00008c7e0 sp=0xc00008c750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00008c7e8 sp=0xc00008c7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 21 [GC worker (idle)]:
+runtime.gopark(0xa740c76b8ab?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004bf50 sp=0xc00004bf30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004bfe0 sp=0xc00004bf50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 22 [GC worker (idle)]:
+runtime.gopark(0xa740cc9dc5e?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004c750 sp=0xc00004c730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004c7e0 sp=0xc00004c750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004c7e8 sp=0xc00004c7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 23 [GC worker (idle)]:
+runtime.gopark(0x654640?, 0x1?, 0xba?, 0x5f?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004cf50 sp=0xc00004cf30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004cfe0 sp=0xc00004cf50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 24 [GC worker (idle)]:
+runtime.gopark(0xa740c58ec16?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004d750 sp=0xc00004d730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004d7e0 sp=0xc00004d750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004d7e8 sp=0xc00004d7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 34 [GC worker (idle)]:
+runtime.gopark(0x654640?, 0x1?, 0x7a?, 0xa3?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090f50 sp=0xc000090f30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc000090fe0 sp=0xc000090f50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000090fe8 sp=0xc000090fe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+exit status 2
+```
+
+</details>
diff --git a/results/classifier/zero-shot/118/peripherals/2178 b/results/classifier/zero-shot/118/peripherals/2178
new file mode 100644
index 00000000..0318fab7
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2178
@@ -0,0 +1,47 @@
+peripherals: 0.993
+network: 0.989
+architecture: 0.949
+device: 0.933
+graphic: 0.900
+arm: 0.898
+performance: 0.876
+virtual: 0.795
+user-level: 0.760
+semantic: 0.725
+mistranslation: 0.715
+boot: 0.660
+register: 0.629
+assembly: 0.616
+ppc: 0.614
+permissions: 0.596
+PID: 0.563
+socket: 0.489
+debug: 0.451
+vnc: 0.365
+kernel: 0.279
+hypervisor: 0.267
+x86: 0.260
+risc-v: 0.244
+files: 0.143
+VMM: 0.110
+TCG: 0.082
+i386: 0.078
+KVM: 0.041
+
+USB passthrough on Apple Silicon is unusable
+Description of problem:
+I can't get USB passthrough to work sufficiently well with wifi modems such as the RTL8187L or Atheros AR 9271.
+
+I only use the VM as a router since the host OS doesn't have drivers for any external wifi modems. This is a setup I've used flawlessly many times in the past with other VMs on x86 platforms for many years, but with ARM it's been one fail after another. Parallels does work with the exact same host and guest, but fails in the networking area (plus it's expensive and overkill for something this simple). I mention this because I know the guest drivers work 100% with a different VM.
+Steps to reproduce:
+1. Run any Linux on QEMU on any Apple Silicon mac
+2. Attempt to use a Atheros AR 9271 USB device
+3. Various fails including 
+      a) USB device not showing up (lsusb)
+      b) device shows up and Linux attempts to attach driver, but fails (lsmod shows driver loaded but no interface listed on iwconfig)
+      c) interface shows up (never got the Atheros this far, but RealTek does) but the interface is slow, corrupts data, etc. 
+      d) after re-attaching several times it will eventually stop attaching at all requiring a MacOS system reboot, which is really annoying for my workflow.
+
+It's basically non-functional for me. Atheros is 100% non-functional and RealTek 10% works (well enough to *sometimes* connect to the AP, but usually craps the bed if you try to do anything as simple as run a dhcp client to fetch the IP).
+
+If anyone knows of any other Linux ARM on Mac ARM vm solutions that allow USB passthrough please let me know. Unfortunately, VirtualBox os currently not one of them.
diff --git a/results/classifier/zero-shot/118/peripherals/2181 b/results/classifier/zero-shot/118/peripherals/2181
new file mode 100644
index 00000000..f67f2a49
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2181
@@ -0,0 +1,33 @@
+peripherals: 0.914
+device: 0.826
+performance: 0.635
+arm: 0.629
+network: 0.577
+architecture: 0.462
+boot: 0.418
+risc-v: 0.411
+semantic: 0.369
+graphic: 0.356
+VMM: 0.328
+vnc: 0.267
+PID: 0.239
+i386: 0.210
+x86: 0.181
+TCG: 0.181
+kernel: 0.167
+ppc: 0.161
+register: 0.156
+debug: 0.141
+mistranslation: 0.136
+socket: 0.134
+virtual: 0.111
+hypervisor: 0.087
+KVM: 0.080
+assembly: 0.056
+user-level: 0.052
+permissions: 0.022
+files: 0.019
+
+-icount mips/gips/kips options on QEMU for more advanced icount option
+Additional information:
+Changing IPS in QEMU affects the frequency of VGA updates, the duration of time before a key starts to autorepeat, and the measurement of BogoMips and other benchmarks.
diff --git a/results/classifier/zero-shot/118/peripherals/2256 b/results/classifier/zero-shot/118/peripherals/2256
new file mode 100644
index 00000000..9848539a
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2256
@@ -0,0 +1,31 @@
+peripherals: 0.953
+graphic: 0.888
+performance: 0.683
+mistranslation: 0.595
+debug: 0.445
+risc-v: 0.366
+semantic: 0.345
+device: 0.271
+boot: 0.231
+ppc: 0.128
+permissions: 0.119
+register: 0.092
+arm: 0.082
+vnc: 0.073
+files: 0.071
+virtual: 0.066
+user-level: 0.064
+i386: 0.063
+assembly: 0.062
+PID: 0.057
+architecture: 0.047
+TCG: 0.043
+network: 0.032
+VMM: 0.029
+hypervisor: 0.027
+socket: 0.021
+kernel: 0.017
+KVM: 0.006
+x86: 0.003
+
+cirrus CI jobs failing
diff --git a/results/classifier/zero-shot/118/peripherals/2307 b/results/classifier/zero-shot/118/peripherals/2307
new file mode 100644
index 00000000..ece6e330
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2307
@@ -0,0 +1,69 @@
+peripherals: 0.896
+virtual: 0.882
+device: 0.878
+user-level: 0.875
+socket: 0.863
+performance: 0.854
+arm: 0.853
+files: 0.849
+permissions: 0.817
+architecture: 0.808
+ppc: 0.801
+graphic: 0.778
+boot: 0.742
+PID: 0.705
+network: 0.691
+kernel: 0.690
+debug: 0.688
+vnc: 0.674
+mistranslation: 0.665
+hypervisor: 0.636
+x86: 0.604
+VMM: 0.564
+KVM: 0.519
+semantic: 0.508
+risc-v: 0.493
+register: 0.444
+TCG: 0.372
+assembly: 0.368
+i386: 0.231
+
+QEMU Windows COM port filenames not recognized i.e. \\.\COM19 or \\.\CNCA0
+Steps to reproduce:
+1. Run qemu-system-arm with the comand line above.
+2. QEMU fails with `qemu-system-arm.exe: -gdb \\.\CNCA8: '\\.\CNCA8' is not a valid char driver`
+3. ```qemu-system-arm.exe -machine mps2-an500 -gdb \\.\COM19
+qemu-system-arm.exe: -gdb \\.\COM19: '\\.\COM19' is not a valid char driver
+```
+Additional information:
+Windows allows COM ports numbered 10 and higher to be prefixed with a `\\.\` escape as in `\\.\COM17`. Such COM port assignments are not uncommon when a plurality of USB serial adapters.
+Equally problematic are virtual COM port designations such as `\\.\CNCA8` created by the Windows 10x64 driver package known as `com0com`: https://pete.akeo.ie/2011/07/com0com-signed-drivers.html
+
+Upon checking the source pulled from the Github mirror an initial fix was to simply modify /chardev/char.c, but this appears insufficient. Sadly.
+
+Please ask if more information is required. I am actively working on extending an existing QEMU machine emulation. A patch to fix this problem is below. Please comment if applicable.
+
+Jerry.
+
+```
+diff --git a/chardev/char.c b/chardev/char.c
+index 3c43fb1278..7a3f342c72 100644
+--- a/chardev/char.c
++++ b/chardev/char.c
+@@ -418,6 +418,13 @@ QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename,
+         qemu_opt_set(opts, "path", filename, &error_abort);
+         return opts;
+     }
++       // JME
++    if (strstart(filename, "\\\\.\\", NULL)) {
++        qemu_opt_set(opts, "backend", "serial", &error_abort);
++        qemu_opt_set(opts, "path", filename, &error_abort);
++        return opts;
++    }
++
+     if (strstart(filename, "file:", &p)) {
+         qemu_opt_set(opts, "backend", "file", &error_abort);
+         qemu_opt_set(opts, "path", p, &error_abort);
+
+```
+/label ~"kind::Bug"
diff --git a/results/classifier/zero-shot/118/peripherals/2308 b/results/classifier/zero-shot/118/peripherals/2308
new file mode 100644
index 00000000..a248a7e8
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2308
@@ -0,0 +1,109 @@
+peripherals: 0.865
+debug: 0.839
+permissions: 0.834
+device: 0.833
+architecture: 0.823
+arm: 0.823
+virtual: 0.821
+register: 0.813
+performance: 0.807
+network: 0.805
+graphic: 0.803
+boot: 0.791
+kernel: 0.786
+TCG: 0.786
+assembly: 0.785
+PID: 0.782
+user-level: 0.782
+semantic: 0.775
+vnc: 0.767
+hypervisor: 0.755
+socket: 0.744
+KVM: 0.740
+files: 0.721
+risc-v: 0.691
+VMM: 0.690
+ppc: 0.685
+x86: 0.646
+i386: 0.634
+mistranslation: 0.627
+
+QEMU Windows COM port setup dialog always invoked and fails if none is available (USB or virtual serial port hardware)
+Description of problem:
+The Windows backend serial port in `chardev/char-win.c` always calls `CommConfigDialog()`. This should display a COM port configuration dialog which does (and can) not persist the COM port settings. If the COM port does not support this action (see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-commconfigdialoga) then the function fails.
+Steps to reproduce:
+1. Currently not possible with QEMU releases as QEMU does not recognize extended COM port specifications like `\\.\COM19` or `\\.\CNCA0`
+Additional information:
+See https://support.microsoft.com/en-gb/topic/howto-specify-serial-ports-larger-than-com9-db9078a5-b7b6-bf00-240f-f749ebfd913e for details on COM port filenames.
+
+I have a patch which 'fixes' this problem by setting the nominated COM port to defaults of `115200,8,N,0` which seems perfectly sensible in 2024. Please contact me for more details. A git diff shown below (with extensive error reporting)
+
+N.B. Markodown will destroy formatting!
+
+```
+diff --git a/chardev/char-win.c b/chardev/char-win.c
+index d4fb44c4dc..a05896ffe9 100644
+--- a/chardev/char-win.c
++++ b/chardev/char-win.c
+@@ -96,12 +96,24 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp)
+     s->file = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, 0, NULL,
+                       OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
+     if (s->file == INVALID_HANDLE_VALUE) {
++        {
++            char buffer[1024] = { 0 };
++            DWORD dw = GetLastError();
++            sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename);
++            OutputDebugString(buffer);
++        }
+         error_setg_win32(errp, GetLastError(), "Failed CreateFile");
+         s->file = NULL;
+         goto fail;
+     }
+
+     if (!SetupComm(s->file, NRECVBUF, NSENDBUF)) {
++        {
++            char buffer[1024] = { 0 };
++            DWORD dw = GetLastError();
++            sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename);
++            OutputDebugString(buffer);
++        }
+         error_setg(errp, "Failed SetupComm");
+         goto fail;
+     }
+@@ -110,9 +122,31 @@ int win_chr_serial_init(Chardev *chr, const char *filename, Error **errp)
+     size = sizeof(COMMCONFIG);
+     GetDefaultCommConfig(filename, &comcfg, &size);
+     comcfg.dcb.DCBlength = sizeof(DCB);
+-    CommConfigDialog(filename, NULL, &comcfg);
+-
++#if 1
++    // JME hardwire. There seems to be no mechanism to simply specify serial port options
++    comcfg.dcb.BaudRate = 115200;
++    comcfg.dcb.Parity = NOPARITY;
++    comcfg.dcb.StopBits = ONESTOPBIT;
++    comcfg.dcb.ByteSize = 8;
++#else
++    {
++        BOOL ret = CommConfigDialog(filename, NULL, &comcfg);
++        if (!ret)
++        {
++            char buffer[1024] = { 0 };
++            DWORD dw = GetLastError();
++            sprintf_s(buffer, 1024, "%s(%d) Error: %d 0x%x %s\r\n", __FILE__, __LINE__, dw, dw, filename);
++            OutputDebugString(buffer);
++        }
++    }
++#endif
+     if (!SetCommState(s->file, &comcfg.dcb)) {
++        {
++            char buffer[1024]={0};
++            DWORD dw = GetLastError();
++            sprintf_s(buffer,1024,"%s(%d) Error: %d 0x%x %s\r\n",__FILE__,__LINE__,dw,dw, filename);
++            OutputDebugString(buffer);
++        }
+         error_setg(errp, "Failed SetCommState");
+         goto fail;
+     }
+```
+
+/label ~"kind::Bug"
diff --git a/results/classifier/zero-shot/118/peripherals/2349 b/results/classifier/zero-shot/118/peripherals/2349
new file mode 100644
index 00000000..eaec3f70
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2349
@@ -0,0 +1,42 @@
+peripherals: 0.961
+graphic: 0.879
+device: 0.800
+semantic: 0.689
+boot: 0.665
+files: 0.645
+socket: 0.529
+VMM: 0.477
+PID: 0.428
+user-level: 0.419
+mistranslation: 0.415
+vnc: 0.408
+ppc: 0.400
+virtual: 0.398
+permissions: 0.393
+risc-v: 0.378
+architecture: 0.371
+kernel: 0.336
+arm: 0.314
+TCG: 0.293
+performance: 0.283
+network: 0.262
+KVM: 0.256
+debug: 0.254
+register: 0.248
+hypervisor: 0.202
+x86: 0.124
+assembly: 0.108
+i386: 0.105
+
+keyboard (and mouse) not working in macOS guest
+Description of problem:
+keyboard not working after exiting EFI environment. it works in the OpenCore boot picker, but not in the recovery system. The mouse can work by forcing the PS2 controller and pause/resume the VM. See here for more details:
+https://github.com/utmapp/UTM/issues/5240#issuecomment-2112477131
+Tried adding ps2 kexts, but qemu USB keyboard, mouse and tablet do not attach to the AppleUSBEHCI bus. It works fine in Snow Leopard only as evident in the picture on the Github issue.
+Steps to reproduce:
+1.Install macOS guest Mavericks through Sierra using https://github.com/royalgraphx/LegacyOSXKVM/blob/main/info/CONVERSIONS.md
+2.https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot-macOS.sh
+3.
+Additional information:
+[command.txt](/uploads/3af8e5476833a1f869debc4fbfe97e84/command.txt)
+[EFI.zip](/uploads/3f49054b496b19244ebb111cf07ed05a/EFI.zip)
diff --git a/results/classifier/zero-shot/118/peripherals/2440 b/results/classifier/zero-shot/118/peripherals/2440
new file mode 100644
index 00000000..d104a0e2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2440
@@ -0,0 +1,142 @@
+peripherals: 0.865
+ppc: 0.823
+x86: 0.814
+hypervisor: 0.804
+TCG: 0.803
+user-level: 0.792
+VMM: 0.787
+vnc: 0.785
+risc-v: 0.780
+mistranslation: 0.778
+KVM: 0.776
+graphic: 0.774
+register: 0.772
+semantic: 0.757
+i386: 0.757
+device: 0.755
+architecture: 0.745
+performance: 0.742
+permissions: 0.738
+virtual: 0.735
+debug: 0.727
+arm: 0.706
+network: 0.702
+assembly: 0.698
+socket: 0.688
+PID: 0.687
+kernel: 0.669
+boot: 0.646
+files: 0.619
+
+virtio-net: Use-After-Free during unrealization of virtio-net
+Description of problem:
+When hotplugging `virtio-net` device, mishandling of `failover` option may leads to use-after-free.
+More specifically, if we try to hotplug virtio-net device with `failover=on` and other invalid option (e.g. `rx_queue_size=0`), the device listner callback is registered but not unregistered before being freed, leading to UAF.
+Steps to reproduce:
+```sh
+cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+device_add virtio-net,failover=on,bus=br1,id=dev0
+quit
+EOF
+```
+
+If above command is not working, let me know so that I provide more information.
+Additional information:
+The following log leveals bug location:
+
+```sh
+$ cat <<EOF | qemu-system-i386 -M q35 -nodefaults -chardev stdio,id=char0 -mon char0 -device pcie-pci-bridge,id=br1,bus=pcie.0
+device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+device_add virtio-net,failover=on,bus=br1,id=dev0
+quit
+EOF
+==836681==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+QEMU 8.1.93 monitor - type 'help' for more information
+VNC server running on 127.0.0.1:5900
+(qemu) device_add virtio-net,failover=on,rx_queue_size=0,bus=br1,id=dev0
+Error: Invalid rx_queue_size (= 0), must be a power of 2 between 256 and 1024.
+(qemu) device_add virtio-net,failover=on,bus=br1,id=dev0
+=================================================================
+==836681==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e00000ab58 at pc 0x5577bbb8fe22 bp 0x7ffeb03fca50 sp 0x7ffeb03fca48
+READ of size 8 at 0x62e00000ab58 thread T0
+    #0 0x5577bbb8fe21 in qdev_should_hide_device /home/XXX/qemu/build/../hw/core/qdev.c:233:23
+    #1 0x5577bb14aac4 in qdev_device_add_from_qdict /home/XXX/qemu/build/../system/qdev-monitor.c:662:9
+    #2 0x5577bb14c364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11
+    #3 0x5577bb14d6eb in qmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:860:11
+    #4 0x5577bb14e11d in hmp_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:968:5
+    #5 0x5577bb29aef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9
+    #6 0x5577bb298fa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9
+    #7 0x5577bb2949ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5
+    #8 0x5577bc2b0c3a in readline_handle_byte /home/XXX/qemu/build/../util/readline.c:419:13
+    #9 0x5577bb29d261 in monitor_read /home/XXX/qemu/build/../monitor/hmp.c:1390:13
+    #10 0x5577bbfda644 in fd_chr_read /home/XXX/qemu/build/../chardev/char-fd.c:72:9
+    #11 0x7f53d36e5c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #12 0x5577bc2536db in glib_pollfds_poll /home/XXX/qemu/build/../util/main-loop.c:290:9
+    #13 0x5577bc2536db in os_host_main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:313:5
+    #14 0x5577bc2536db in main_loop_wait /home/XXX/qemu/build/../util/main-loop.c:592:11
+    #15 0x5577bb15dd06 in qemu_main_loop /home/XXX/qemu/build/../system/runstate.c:782:9
+    #16 0x5577bbb81115 in qemu_default_main /home/XXX/qemu/build/../system/main.c:37:14
+    #17 0x7f53d2c3fd8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
+    #18 0x7f53d2c3fe3f in __libc_start_main csu/../csu/libc-start.c:392:3
+    #19 0x5577ba4c3584 in _start (/usr/local/bin/qemu-system-i386+0x1ada584) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+
+0x62e00000ab58 is located 42840 bytes inside of 43008-byte region [0x62e000000400,0x62e00000ac00)
+freed by thread T1 here:
+    #0 0x5577ba546122 in __interceptor_free (/usr/local/bin/qemu-system-i386+0x1b5d122) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x5577bbba5135 in object_finalize /home/XXX/qemu/build/../qom/object.c:714:9
+    #2 0x5577bbba5135 in object_unref /home/XXX/qemu/build/../qom/object.c:1217:9
+    #3 0x5577bbb91ac3 in bus_free_bus_child /home/XXX/qemu/build/../hw/core/qdev.c:55:5
+
+previously allocated by thread T0 here:
+    #0 0x5577ba5463ce in malloc (/usr/local/bin/qemu-system-i386+0x1b5d3ce) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x7f53d36ee738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) (BuildId: 224ac2a88b72bc8e2fe8566ee28fae789fc69241)
+    #2 0x5577bb14c364 in qdev_device_add /home/XXX/qemu/build/../system/qdev-monitor.c:738:11
+    #3 0x5577bb29aef4 in handle_hmp_command_exec /home/XXX/qemu/build/../monitor/hmp.c:1106:9
+    #4 0x5577bb298fa3 in handle_hmp_command /home/XXX/qemu/build/../monitor/hmp.c:1158:9
+    #5 0x5577bb2949ee in monitor_command_cb /home/XXX/qemu/build/../monitor/hmp.c:47:5
+
+Thread T1 created by T0 here:
+    #0 0x5577ba52f84c in pthread_create (/usr/local/bin/qemu-system-i386+0x1b4684c) (BuildId: c7ca543ea41d3478bc13cdf604d47805b990620e)
+    #1 0x5577bc1fcc24 in qemu_thread_create /home/XXX/qemu/build/../util/qemu-thread-posix.c:581:11
+    #2 0x5577bc229970 in rcu_init_complete /home/XXX/qemu/build/../util/rcu.c:415:5
+    #3 0x5577bc229970 in rcu_init /home/XXX/qemu/build/../util/rcu.c:471:5
+    #4 0x7f53d2c3feba in call_init csu/../csu/libc-start.c:145:3
+    #5 0x7f53d2c3feba in __libc_start_main csu/../csu/libc-start.c:379:5
+
+SUMMARY: AddressSanitizer: heap-use-after-free /home/XXX/qemu/build/../hw/core/qdev.c:233:23 in qdev_should_hide_device
+Shadow bytes around the buggy address:
+  0x0c5c7fff9510: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9520: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9530: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9540: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9550: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+=>0x0c5c7fff9560: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd
+  0x0c5c7fff9570: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c5c7fff9580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c5c7fff9590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c5c7fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c5c7fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+==836681==ABORTING
+```
+
+#
diff --git a/results/classifier/zero-shot/118/peripherals/2448 b/results/classifier/zero-shot/118/peripherals/2448
new file mode 100644
index 00000000..9a8a6191
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2448
@@ -0,0 +1,76 @@
+peripherals: 0.849
+mistranslation: 0.784
+debug: 0.781
+graphic: 0.773
+register: 0.764
+PID: 0.749
+device: 0.730
+vnc: 0.728
+permissions: 0.728
+performance: 0.725
+semantic: 0.721
+user-level: 0.709
+risc-v: 0.702
+boot: 0.684
+hypervisor: 0.681
+ppc: 0.671
+socket: 0.668
+TCG: 0.663
+files: 0.654
+arm: 0.649
+network: 0.648
+kernel: 0.622
+architecture: 0.611
+assembly: 0.592
+VMM: 0.569
+virtual: 0.554
+x86: 0.544
+KVM: 0.505
+i386: 0.381
+
+linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin
+Description of problem:
+When a `*-linux-user` is used as binfmt_misc, and...
+
+- The `O` (i.e. open-binary) flag is set
+- File descriptor 0 is closed when running the executable
+
+FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable.
+
+Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior.
+Steps to reproduce:
+1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary)
+2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`)
+3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output)
+
+The correct behavior is (You can see by running the native `cat <&-`):
+
+```
+cat: -: Bad file descriptor
+cat: closing standard input: Bad file descriptor
+```
+
+Instead, the executable `cat` itself is dumped to stdout.
+
+Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable.
+Additional information:
+I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far:
+
+In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765)
+
+```c
+    execfd = qemu_getauxval(AT_EXECFD);
+    if (execfd == 0) {
+        execfd = open(exec_path, O_RDONLY);
+        if (execfd < 0) {
+            printf("Error while loading %s: %s\n", exec_path, strerror(errno));
+            _exit(EXIT_FAILURE);
+        }
+    }
+```
+
+However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value.
+
+`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`.
+
+Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay?
diff --git a/results/classifier/zero-shot/118/peripherals/2462 b/results/classifier/zero-shot/118/peripherals/2462
new file mode 100644
index 00000000..4acd39eb
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2462
@@ -0,0 +1,69 @@
+peripherals: 0.928
+performance: 0.919
+ppc: 0.897
+user-level: 0.856
+PID: 0.832
+architecture: 0.817
+graphic: 0.811
+permissions: 0.753
+debug: 0.737
+network: 0.716
+device: 0.712
+arm: 0.683
+semantic: 0.672
+files: 0.653
+hypervisor: 0.622
+kernel: 0.615
+assembly: 0.611
+TCG: 0.601
+socket: 0.584
+risc-v: 0.582
+x86: 0.569
+vnc: 0.569
+mistranslation: 0.547
+register: 0.541
+i386: 0.526
+boot: 0.497
+virtual: 0.462
+VMM: 0.442
+KVM: 0.421
+
+QEMU SIFIVE reading from stdin hangs
+Description of problem:
+I have a simple test program (C and ASM) that reads from stdin.  When i was using the qemu provided by Ubuntu, QEMU emulator version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.5), my test was working, and was able to read bytes from stdin.
+
+Using the latest Qemu from git, breaks my test.  I can still print, but now reading hangs, like its always waiting for input but never getting it.
+
+My guess is that this commit breaks my code:
+https://github.com/qemu/qemu/commit/6ee7ba1b8a10bd8eb1d3b918eaaf9f832a51adb4
+
+Before the above commit, `qemu_chr_fe_set_handlers` was being called, and that is what allowed the default behavior of reading from stdin is on by default?
+
+from sifive_uart.c
+```
+    qemu_chr_fe_set_handlers(&s->chr, sifive_uart_can_rx, sifive_uart_rx,
+                             sifive_uart_event, sifive_uart_be_change, s,
+                             NULL, true);
+```
+Steps to reproduce:
+1. compile simple C program that calls `read` reading a single byte from stdin
+2. do not initialize UART options
+3. run in QEMU, send input, hangs.
+Additional information:
+Other examples online, like riscv-probe, use a uart init function like below:
+```
+static void sifive_uart_init()
+{
+    uart = (int *)(void *)getauxval(SIFIVE_UART0_CTRL_ADDR);
+    uint32_t uart_freq = getauxval(UART0_CLOCK_FREQ);
+    uint32_t baud_rate = getauxval(UART0_BAUD_RATE);
+    uint32_t divisor = uart_freq / baud_rate - 1;
+    uart[UART_REG_DIV] = divisor;
+    uart[UART_REG_TXCTRL] = UART_TXEN;
+    uart[UART_REG_RXCTRL] = UART_RXEN;
+    uart[UART_REG_IE] = 0;
+}
+```
+
+However, when I was using QEMU 8.0.4, i did not have to write a function like above to init UART, because stdin and stdout were working out of the box.
+Below is my C and ASM:
diff --git a/results/classifier/zero-shot/118/peripherals/2485 b/results/classifier/zero-shot/118/peripherals/2485
new file mode 100644
index 00000000..6094cadc
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2485
@@ -0,0 +1,77 @@
+peripherals: 0.968
+architecture: 0.925
+user-level: 0.785
+graphic: 0.778
+debug: 0.735
+ppc: 0.719
+performance: 0.653
+device: 0.609
+mistranslation: 0.600
+semantic: 0.588
+files: 0.533
+network: 0.411
+kernel: 0.403
+permissions: 0.399
+PID: 0.386
+boot: 0.363
+virtual: 0.363
+assembly: 0.355
+socket: 0.346
+risc-v: 0.327
+TCG: 0.309
+arm: 0.298
+x86: 0.292
+vnc: 0.290
+register: 0.284
+VMM: 0.239
+hypervisor: 0.217
+i386: 0.205
+KVM: 0.091
+
+getifaddrs linked with musl libc hangs on big-endian targets
+Description of problem:
+When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success.
+
+```c
+#include <stdlib.h>
+#include <ifaddrs.h>
+
+int
+main (void)
+{
+
+    struct ifaddrs *ifa = 0;
+    int error;
+
+    error = getifaddrs(&ifa);
+    if (error || !ifa)
+        exit(1);
+    else
+        exit(0);
+
+    return 0;
+}
+```
+Steps to reproduce:
+1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/))
+2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`)
+3. Observe that the process hangs.
+Additional information:
+This has come up elsewhere:
+
+* https://bugs.gentoo.org/914256
+* https://www.openwall.com/lists/musl/2018/05/30/4
+* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain)
+* Likely affects sparc but that port/toolchain is also a WIP
+
+Here are some static sample binaries for the above program:
+
+* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later)
+
+GitLab labels seem to be missing:
+
+* ~"kind::Bug"
+* ~"linux-user"
+* ~"target: ppc"
+* ~"target: m68k"
+* ~"target: s390x"
diff --git a/results/classifier/zero-shot/118/peripherals/2487 b/results/classifier/zero-shot/118/peripherals/2487
new file mode 100644
index 00000000..23ece808
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2487
@@ -0,0 +1,98 @@
+peripherals: 0.826
+graphic: 0.814
+debug: 0.760
+permissions: 0.730
+risc-v: 0.725
+PID: 0.707
+device: 0.696
+x86: 0.693
+vnc: 0.681
+files: 0.670
+TCG: 0.668
+architecture: 0.664
+i386: 0.660
+socket: 0.653
+arm: 0.641
+network: 0.639
+performance: 0.639
+register: 0.637
+semantic: 0.632
+hypervisor: 0.615
+ppc: 0.612
+boot: 0.593
+user-level: 0.571
+VMM: 0.548
+mistranslation: 0.503
+virtual: 0.501
+kernel: 0.500
+KVM: 0.466
+assembly: 0.296
+
+qemu-x86_64: qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached
+Description of problem:
+Using this basic test file:
+
+```c
+int
+main (void)
+{
+    return 0;
+}
+```
+
+compiled into a static executable using an x86_64 toolchain (glibc or musl both tested),
+
+```
+gwyn ~/qemu-bug # file test1
+test1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped
+
+gwyn ~/qemu-bug # file test2
+test2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=276dc49ee7cbd3b760e24761bf9fb9e1cc4b4349, for GNU/Linux 3.2.0, not stripped
+```
+
+Using QEMU from 15957eb9efe2da67c796612cead95cba28ba9bda or newer:
+
+```
+gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 --version
+qemu-x86_64 version 9.0.50 (v9.0.0-521-g15957eb9ef-dirty)
+Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers
+```
+
+QEMU crashes:
+
+```
+gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 ./test2
+**
+ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached
+Bail out! ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached
+Aborted
+```
+Steps to reproduce:
+1. Build QEMU user for ppc64 (may affect other hosts) using commit 15957eb9efe2da67c796612cead95cba28ba9bda or newer.
+2. Run any simple x86_64 executable.
+3. Observe the crash.
+Additional information:
+Bisected to here:
+
+```
+commit 15957eb9efe2da67c796612cead95cba28ba9bda
+Author: Paolo Bonzini <pbonzini@redhat.com>
+Date:   Fri Oct 27 05:57:31 2023 +0200
+
+    target/i386: use TSTEQ/TSTNE to test low bits
+    
+    When testing the sign bit or equality to zero of a partial register, it
+    is useful to use a single TSTEQ or TSTNE operation.  It can also be used
+    to test the parity flag, using bit 0 of the population count.
+    
+    Do not do this for target_ulong-sized values however; the optimizer would
+    produce a comparison against zero anyway, and it avoids shifts by 64
+    which are undefined behavior.
+    
+    Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
+    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+ target/i386/tcg/emit.c.inc  |  5 ++---
+ target/i386/tcg/translate.c | 28 ++++++++++++++++++++--------
+ 2 files changed, 22 insertions(+), 11 deletions(-)
+```
diff --git a/results/classifier/zero-shot/118/peripherals/2498 b/results/classifier/zero-shot/118/peripherals/2498
new file mode 100644
index 00000000..826dc6b7
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2498
@@ -0,0 +1,81 @@
+peripherals: 0.863
+performance: 0.813
+files: 0.805
+arm: 0.770
+register: 0.770
+debug: 0.753
+socket: 0.727
+PID: 0.724
+hypervisor: 0.719
+boot: 0.713
+ppc: 0.682
+architecture: 0.674
+kernel: 0.667
+graphic: 0.664
+TCG: 0.662
+risc-v: 0.657
+permissions: 0.656
+network: 0.647
+vnc: 0.639
+virtual: 0.620
+semantic: 0.610
+VMM: 0.590
+device: 0.584
+x86: 0.579
+mistranslation: 0.564
+user-level: 0.561
+i386: 0.543
+KVM: 0.512
+assembly: 0.492
+
+m68k: fpu: fmovem with multiple control registers has incorrect in memory order
+Description of problem:
+It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers.
+
+According to the manual:
+
+```
+The
+registers are always moved in the same order, regardless of the addressing mode
+used; the floating-point control register is moved first, followed by the floating-point
+status register, and the floating-point instruction address register is moved last.
+```
+
+Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary.
+
+Maybe something like this is needed:
+
+``` diff
+commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt)
+Author: Daniel Palmer <daniel@thingy.jp>
+Date:   Tue Aug 13 09:52:54 2024 +0900
+
+    fix fmovem ordering
+
+diff --git a/target/m68k/translate.c b/target/m68k/translate.c
+index 92dc9d8563..64ff2df06e 100644
+--- a/target/m68k/translate.c
++++ b/target/m68k/translate.c
+@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s,
+      */
+ 
+     if (is_write && mode == 4) {
+-        for (i = 2; i >= 0; i--, mask >>= 1) {
+-            if (mask & 1) {
++        for (i = 2; i >= 0; i--, mask <<= 1) {
++            if (mask & 0b100) {
+                 gen_qemu_store_fcr(s, addr, 1 << i);
+                 if (mask != 1) {
+                     tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG));
+@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s,
+        }
+        tcg_gen_mov_i32(AREG(insn, 0), addr);
+     } else {
+-        for (i = 0; i < 3; i++, mask >>= 1) {
+-            if (mask & 1) {
++        for (i = 2; i >= 0; i--, mask <<= 1) {
++            if (mask & 0b100) {
+                 if (is_write) {
+                     gen_qemu_store_fcr(s, addr, 1 << i);
+                 } else {
+```
diff --git a/results/classifier/zero-shot/118/peripherals/2521 b/results/classifier/zero-shot/118/peripherals/2521
new file mode 100644
index 00000000..5d57d2e0
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2521
@@ -0,0 +1,46 @@
+peripherals: 0.953
+files: 0.853
+device: 0.822
+performance: 0.778
+kernel: 0.746
+architecture: 0.716
+hypervisor: 0.691
+semantic: 0.669
+assembly: 0.581
+graphic: 0.580
+boot: 0.498
+x86: 0.492
+PID: 0.483
+user-level: 0.470
+permissions: 0.469
+VMM: 0.461
+register: 0.450
+socket: 0.429
+virtual: 0.396
+debug: 0.391
+ppc: 0.373
+risc-v: 0.331
+network: 0.302
+vnc: 0.299
+i386: 0.289
+KVM: 0.280
+TCG: 0.264
+mistranslation: 0.252
+arm: 0.225
+
+USB Passthrough Improper Remote Wakeup
+Description of problem:
+I am doing research with Linux Power Management interactions with USB devices. Which is why I would like to be able to wake a qemu vm from suspend with a passed through USB device. The first issue is that remote wakeup from usb devices do not wake the vm at all when running in -nographic mode (issuing system_wakeup from a qemu monitor shell will wake it though). When running with a GUI it is possible to wake the vm from a usb device as well as the qemu monitor shell but both will result in the GUI screen being black afterwards. It is still possible to use the vm though. Finally, waking the vm with a usb device is only possible when a valid usb device is passed through in the qemu launch command line. But interestingly the usb device specified to be passed through will only wakeup the vm if it is unplugged and plugged back in during the suspend. All other usb devices can wakeup the vm normally even though they are not passed through. It is not clear to me what is going on here and why other devices not being passed through to qemu can wake the vm. Note I have also enabled the /sys/bus/usb/devices/usb#/power/wakeup file and have manually unsuppressed the remote_wakeup flag in the source code to enable the /sys/bus/usb/devices/#-#/power/wakeup files to be generated but it has not affected anything.
+Steps to reproduce:
+I have tested this issue with multiple kernel versions (6.10, 6.10-rc4, 6.6.43) as well as custom and generic kernel configs and different debian images so these do not seem to be the problem. But here is a detailed description of the exact setup I am currently using:
+
+1. Download linux-6.10-rc4 source and configure with syzkaller fuzzing config https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-usb.config 
+2. Set CONFIG_KCOV_INSTRUMENT_ALL to off (breaks suspend/resume in vm) and create bzImage
+2. Create a debian bookworm image with syzkaller script https://github.com/google/syzkaller/blob/master/tools/create-image.sh
+3. Download and build Qemu from source (see attached for detailed configuration and dependencies)
+4. Attach a usb keyboard and mouse
+5. Choose one device to pass through via command line
+6. Try waking the vm with nographic and graphic mode using the usb devices
+Additional information:
+[configuration_output.txt](/uploads/f7d3487dab65deef40bd0e110b64a573/configuration_output.txt)
+[gui_wakeup_log.txt](/uploads/72b192a88d587eced4bb4032307307e5/gui_wakeup_log.txt)
diff --git a/results/classifier/zero-shot/118/peripherals/2589 b/results/classifier/zero-shot/118/peripherals/2589
new file mode 100644
index 00000000..8a64d61d
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2589
@@ -0,0 +1,86 @@
+peripherals: 0.836
+performance: 0.761
+hypervisor: 0.760
+KVM: 0.756
+graphic: 0.753
+permissions: 0.740
+boot: 0.719
+semantic: 0.712
+device: 0.711
+assembly: 0.707
+user-level: 0.707
+PID: 0.706
+virtual: 0.705
+ppc: 0.700
+risc-v: 0.697
+debug: 0.695
+register: 0.693
+arm: 0.692
+files: 0.689
+TCG: 0.678
+architecture: 0.666
+vnc: 0.641
+mistranslation: 0.633
+network: 0.606
+VMM: 0.586
+kernel: 0.580
+socket: 0.513
+x86: 0.501
+i386: 0.373
+
+Support guest shutdown of Alpine Linux in guest agent
+Description of problem:
+The qemu-guest-agent's shutdown calls `/sbin/shutdown` with the apropriate flags to shut down a posix system. On Alpine Linux, which is based on busybox, there is no `/sbin/shutdown`, instead there are `/sbin/poweroff`, `/sbin/halt` and `/sbin/reboot`. We have used a downstream patch for years that will exec those as a fallback in case execing `/sbin/shutdown` fails.
+
+With qemu 9.2 this patch no longer applies and it is probably time to solve this properly in upstream qemu.
+
+The question is how?
+
+Some options:
+
+- Set the powerdown, halt and reboot commands via build time configure option
+- Add a fallback if the `execlp` fails (similar to what downstream Alpine's patch does now). We could for example give `ga_run_command` a `const char **argv[]`, and try `execvp` all of them before erroring out.
+- Test the existence of `/sbin/shutdown` before calling `ga_run_command`.
+- Do nothing. Let downstream Alpine Linux handle it.
+Steps to reproduce:
+1. Build qemu-guest-agent for Alpine Linux
+2. boot a Alpine linux VM and install the qemu-guest-agent
+3. Try shutdown the VM via qmp command.
+Additional information:
+The patch that we previously used that no longer applies:
+```diff
+diff --git a/qga/commands-posix.c b/qga/commands-posix.c
+index 954efed01..61427652c 100644
+--- a/qga/commands-posix.c
++++ b/qga/commands-posix.c
+@@ -84,6 +84,7 @@ static void ga_wait_child(pid_t pid, int *status, Error **errp)
+ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp)
+ {
+     const char *shutdown_flag;
++    const char *fallback_cmd = NULL;
+     Error *local_err = NULL;
+     pid_t pid;
+     int status;
+@@ -101,10 +102,13 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp)
+     slog("guest-shutdown called, mode: %s", mode);
+     if (!has_mode || strcmp(mode, "powerdown") == 0) {
+         shutdown_flag = powerdown_flag;
++        fallback_cmd = "/sbin/poweroff";
+     } else if (strcmp(mode, "halt") == 0) {
+         shutdown_flag = halt_flag;
++        fallback_cmd = "/sbin/halt";
+     } else if (strcmp(mode, "reboot") == 0) {
+         shutdown_flag = reboot_flag;
++        fallback_cmd = "/sbin/reboot";
+     } else {
+         error_setg(errp,
+                    "mode is invalid (valid values are: halt|powerdown|reboot");
+@@ -125,6 +129,7 @@ void qmp_guest_shutdown(bool has_mode, const char *mode, Error **errp)
+ #else
+         execl("/sbin/shutdown", "shutdown", "-h", shutdown_flag, "+0",
+                "hypervisor initiated shutdown", (char *)NULL);
++        execle(fallback_cmd, fallback_cmd, (char*)NULL, environ);
+ #endif
+         _exit(EXIT_FAILURE);
+     } else if (pid < 0) {
+```
diff --git a/results/classifier/zero-shot/118/peripherals/2694 b/results/classifier/zero-shot/118/peripherals/2694
new file mode 100644
index 00000000..cb022007
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2694
@@ -0,0 +1,54 @@
+peripherals: 0.872
+hypervisor: 0.838
+mistranslation: 0.821
+x86: 0.819
+graphic: 0.814
+arm: 0.803
+debug: 0.793
+performance: 0.790
+risc-v: 0.787
+vnc: 0.782
+VMM: 0.781
+TCG: 0.778
+semantic: 0.776
+permissions: 0.768
+device: 0.755
+KVM: 0.748
+network: 0.747
+register: 0.737
+ppc: 0.736
+user-level: 0.727
+files: 0.724
+PID: 0.724
+i386: 0.722
+kernel: 0.707
+virtual: 0.705
+boot: 0.683
+architecture: 0.677
+socket: 0.655
+assembly: 0.626
+
+error: implicit declaration of function 'IOMainPort' is invalid in C99
+Description of problem:
+Build in MacOS
+    Hardware Overview:
+
+      Model Name: MacBook Air
+      Chip: Apple M1
+      Total Number of Cores: 8 (4 performance and 4 efficiency)
+      Memory: 16 GB
+Steps to reproduce:
+1. ./configure --cpu=aarch64 --target-list=aarch64-softmmu --enable-slirp
+2. make -j
+Additional information:
+```
+FAILED: libblock.a.p/block_file-posix.c.o
+cc -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/opt/homebrew/opt/zstd/include -I/opt/homebrew/Cellar/glib/2.82.2/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.82.2/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.44/include -I/opt/homebrew/Cellar/glib/2.82.2/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/august/qemu/src -iquote /Users/august/qemu/src/include -iquote /Users/august/qemu/src/host/include/aarch64 -iquote /Users/august/qemu/src/host/include/generic -iquote /Users/august/qemu/src/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c
+../block/file-posix.c:3940:18: error: implicit declaration of function 'IOMainPort' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
+    kernResult = IOMainPort(MACH_PORT_NULL, &mainPort);
+                 ^
+1 error generated.
+ninja: build stopped: subcommand failed.
+make[1]: *** [run-ninja] Error 1
+make: *** [build] Error 2
+```
diff --git a/results/classifier/zero-shot/118/peripherals/2705 b/results/classifier/zero-shot/118/peripherals/2705
new file mode 100644
index 00000000..1c9756cb
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2705
@@ -0,0 +1,47 @@
+peripherals: 0.981
+architecture: 0.952
+boot: 0.931
+device: 0.926
+performance: 0.915
+virtual: 0.910
+vnc: 0.865
+semantic: 0.851
+x86: 0.845
+graphic: 0.845
+ppc: 0.818
+debug: 0.771
+arm: 0.743
+mistranslation: 0.726
+user-level: 0.721
+socket: 0.687
+hypervisor: 0.667
+permissions: 0.665
+VMM: 0.631
+risc-v: 0.625
+register: 0.615
+files: 0.565
+PID: 0.548
+KVM: 0.519
+TCG: 0.499
+assembly: 0.499
+i386: 0.473
+kernel: 0.422
+network: 0.411
+
+USB event delivery does not work correctly for macOS guests with XHCI controller without MSI(-X)
+Steps to reproduce:
+1. Get a macOS VM working. Either on x86-64 with a Q35 machine type, AppleSMC device, and OpenCore bootloader, or on aarch64 using the patch set and instructions linked above.
+2. On x86-64, switch to a NEC XHCI controller with MSI and MSI-X support forcibly disabled: `-device nec-usb-xhci,id=xhci,msi=off,msix=off`
+3. Boot macOS.
+
+USB events are now extremely laggy. A USB keyboard or mouse becomes almost unusable.
+
+
+While narrowing down the problem, I established the following facts by experimentation, tracing, and code inspection:
+
+ * Although the vmapple platform uses an emulated XHCI PCI device for connecting virtual USB devices, it does not support message-signalled interrupts, in either the MSI or MSI-X persuasion. (This is true in Apple's implementation as well, but the macOS guest's XHCI driver unsurprisingly does work with Apple's PCI/XHCI implementation.)
+ * macOS guests (and the iBoot bootloader) appear to refuse to drive XHCI controllers with `numintrs < 4`, for both aarch64 and x86-64 architectures. They will generally set up event rings 0, 1, and 2.
+ * QEMU's PCI XHCI implementation does not appear to implement (as of 9.2.0-rc2) any mitigations for when the controller is used in pin-based IRQ mode. It will happily attempt to use event rings >0 in this case, but interrupts are dropped.
+ * Linux and FreeBSD guests appear to use only interrupter 0 anyway, so these are not useful references.
+
+It's not entirely clear to me what component is ultimately responsible for the failure here - I suspect there might be some not-quite-right behaviour in both macOS's XHCI driver and Qemu's XHCI implementation, and that these conspire to a non-functional setup.
diff --git a/results/classifier/zero-shot/118/peripherals/2788 b/results/classifier/zero-shot/118/peripherals/2788
new file mode 100644
index 00000000..aede35c7
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2788
@@ -0,0 +1,43 @@
+peripherals: 0.996
+virtual: 0.988
+x86: 0.945
+boot: 0.939
+device: 0.922
+semantic: 0.908
+graphic: 0.787
+user-level: 0.766
+performance: 0.765
+mistranslation: 0.728
+register: 0.670
+vnc: 0.646
+architecture: 0.641
+PID: 0.617
+KVM: 0.603
+permissions: 0.578
+socket: 0.549
+debug: 0.543
+kernel: 0.498
+ppc: 0.496
+VMM: 0.490
+files: 0.478
+network: 0.444
+assembly: 0.369
+i386: 0.365
+hypervisor: 0.325
+TCG: 0.323
+risc-v: 0.306
+arm: 0.173
+
+[solved] input mouse and keyboard not working on a distro
+Description of problem:
+The distro work but does not take input from either keyboard or mouse.
+At the boot menu (syslinux) where I have to choose the boot mode the keyboard works, but it stops working when the desktop has booted.
+The distro is not blocked I can tell by observing that the clock in the panel keeps running and if I click in the qemu menubar on machine > power down, the distro correctly performs the shutdown procedure.
+I have tried other distributions (porteus and tinycore) and both do not have this problem.
+I also tried using as -display vnc and sdl but I have the same problem.
+I am using a [portable version of qemu](https://gitlab.com/qemu-project/qemu/-/issues/new) but I also tried with the repository version having the same problem.
+Steps to reproduce:
+Simply boot the virtual machine with the distro, in my case with the portable qemu version:
+./QEMU-git-x86_64.AppImage qemu-system-x86_64 -m 512 -enable-kvm -boot d -cdrom ./Nemesis-v25.01-XFCE-x86_64.iso
+Additional information:
+I am not expert in qemu, if you need some more data I can try to produce it
diff --git a/results/classifier/zero-shot/118/peripherals/2826 b/results/classifier/zero-shot/118/peripherals/2826
new file mode 100644
index 00000000..8fc44325
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2826
@@ -0,0 +1,39 @@
+peripherals: 0.974
+graphic: 0.955
+device: 0.866
+kernel: 0.847
+architecture: 0.816
+ppc: 0.770
+semantic: 0.700
+boot: 0.689
+performance: 0.621
+debug: 0.557
+network: 0.553
+VMM: 0.497
+PID: 0.496
+files: 0.473
+register: 0.455
+user-level: 0.444
+vnc: 0.359
+mistranslation: 0.329
+TCG: 0.198
+permissions: 0.185
+risc-v: 0.129
+assembly: 0.107
+socket: 0.093
+hypervisor: 0.092
+virtual: 0.085
+arm: 0.014
+i386: 0.006
+x86: 0.004
+KVM: 0.002
+
+The host PCI bridge disappeared on the big endian MIPS Malta machine
+Description of problem:
+The tests/avocado/linux_ssh_mips_malta.py test currently fails for the big endian machines. It tries to check for the PCI host bridge with ``lspci -d 11ab:4620``, but that does not show the expected output anymore -- it looks like the host bridge cannot be correctly discovered by the guest Linux kernel anymore.
+Steps to reproduce:
+1. Get the kernel and disk image from https://people.debian.org/~aurel32/qemu/mips/
+2. Boot the guest as described above.
+3. lspci -d 11ab:4620
+Additional information:
+This used to work fine before commit 145e2198d749ec09a405f1607a9932499b76f1eb , so this rework likely introduced the bug. Looking at the code that got removed there, I could see an additional check ``phb->config_reg & 0x00fff800`` that is not present in the new code anymore, so the space for the host bridge itself likely should not get swapped. Reverting 3d85c7c15fc7ce986cf1a8e73da1217228f35685 and 145e2198d749ec09a405f1607a9932499b76f1eb seems to fix the problem (at least on little endian hosts).
diff --git a/results/classifier/zero-shot/118/peripherals/2860 b/results/classifier/zero-shot/118/peripherals/2860
new file mode 100644
index 00000000..fbc74d69
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2860
@@ -0,0 +1,63 @@
+peripherals: 0.978
+debug: 0.971
+graphic: 0.958
+device: 0.938
+virtual: 0.925
+KVM: 0.922
+boot: 0.913
+ppc: 0.904
+PID: 0.896
+performance: 0.859
+hypervisor: 0.809
+architecture: 0.775
+VMM: 0.766
+socket: 0.701
+kernel: 0.692
+network: 0.676
+semantic: 0.658
+mistranslation: 0.654
+permissions: 0.642
+risc-v: 0.628
+vnc: 0.592
+TCG: 0.591
+x86: 0.556
+arm: 0.550
+register: 0.538
+i386: 0.527
+files: 0.476
+user-level: 0.448
+assembly: 0.397
+
+ps2 keyboard not work after boot and use libspice to connect it
+Description of problem:
+When I start almost 10 qemu virtual machines, there will always be one or two that have the ps2 keyboard not work well after booted.But I use mstsc to connect to the desktop, the keyboard works fine. But when reboot or migrate it well recovery.
+Steps to reproduce:
+1.Asynchronously start 40 qemu virtual machines, each with 4 cores and 4 threads
+
+2.there will always be one or two that have the ps2 keyboard not work well.
+
+4.And when i gdb debug it, i found i hang at the func "prepare_mmio_access"
+
+5.reboot or migrate it well recovery
+Additional information:
+the gdb debug as fllow:
+
+gdb attach $pid 
+
+gdb>b kbd_push_key      //spice input
+
+gdb>b kbd_read_data
+
+gdb>b ps2_keyboard_event
+
+gdb>c
+
+After continue, the code run on ps2_keyboard_event,but no work to "kbd_read_data".This Proves that the keyboard input has been added to the queue, but has not been read from the queue.
+
+gdb> thread 4   //switch to thread "CPU 0/KVM"
+
+gdb> bt
+
+![image](/uploads/82527d2b382cacd2d4e40793d78d3e59/image.png)
+
+I guess there is no event to notify the device to read after writing to the queue, or is it deadlocked? I'm not sure
diff --git a/results/classifier/zero-shot/118/peripherals/2864 b/results/classifier/zero-shot/118/peripherals/2864
new file mode 100644
index 00000000..44a4b7b5
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2864
@@ -0,0 +1,39 @@
+peripherals: 0.996
+ppc: 0.979
+graphic: 0.974
+device: 0.925
+boot: 0.903
+performance: 0.732
+semantic: 0.693
+register: 0.588
+architecture: 0.581
+permissions: 0.502
+debug: 0.494
+vnc: 0.489
+network: 0.467
+PID: 0.448
+TCG: 0.444
+socket: 0.426
+hypervisor: 0.426
+i386: 0.354
+arm: 0.352
+mistranslation: 0.350
+x86: 0.318
+VMM: 0.302
+user-level: 0.257
+risc-v: 0.229
+assembly: 0.149
+files: 0.148
+virtual: 0.128
+kernel: 0.066
+KVM: 0.008
+
+qemu-system-ppc -M g3beige mouse/keyboard behave erraticaly at least since 9.0
+Description of problem:
+Mouse behaves very erraticaly, seemingly clicks on its own, moves auto-opened terminal window to the left
+Steps to reproduce:
+1. Get helenOS from https://www.helenos.org/wiki/Download
+2. Boot it (need 256 Mb)
+3. Try to move mouse or type anything in Terminal
+Additional information:
+Seemingly same issue present on netBSD (booted on qemu 9.0.4 due to regression in qemu), and macos X/9 when booted on this machine or -M mac99,via=cuda
diff --git a/results/classifier/zero-shot/118/peripherals/2888 b/results/classifier/zero-shot/118/peripherals/2888
new file mode 100644
index 00000000..904c9427
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2888
@@ -0,0 +1,44 @@
+peripherals: 0.952
+device: 0.909
+graphic: 0.871
+kernel: 0.853
+performance: 0.769
+boot: 0.750
+semantic: 0.739
+mistranslation: 0.717
+permissions: 0.668
+vnc: 0.575
+arm: 0.549
+user-level: 0.549
+socket: 0.547
+ppc: 0.546
+PID: 0.511
+virtual: 0.495
+register: 0.470
+architecture: 0.463
+network: 0.436
+VMM: 0.383
+risc-v: 0.376
+debug: 0.374
+TCG: 0.368
+KVM: 0.265
+files: 0.233
+assembly: 0.184
+i386: 0.164
+x86: 0.150
+hypervisor: 0.059
+
+mouse pointer does not move in USB pass in.
+Description of problem:
+I have this script to start qemu that passes in my mouse, keyboard and xbox controller. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move.
+Steps to reproduce:
+1. use the script above with the right USB IDs for you mouse and keyboard (and controller if you want)
+2. When the VM boots it will not move the cursor. The mouse will work but the pointer stays still.
+Additional information:
+I am using thees patches in qemu but it does not work in vanilla ether:
+https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/
+
+and this in the kernel (6.14.0):
+https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83
+
+I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0.
diff --git a/results/classifier/zero-shot/118/peripherals/2889 b/results/classifier/zero-shot/118/peripherals/2889
new file mode 100644
index 00000000..b198e7f0
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2889
@@ -0,0 +1,52 @@
+peripherals: 0.982
+performance: 0.858
+graphic: 0.854
+kernel: 0.845
+device: 0.838
+architecture: 0.751
+user-level: 0.717
+semantic: 0.699
+PID: 0.685
+ppc: 0.600
+virtual: 0.586
+permissions: 0.564
+network: 0.531
+vnc: 0.528
+mistranslation: 0.518
+VMM: 0.472
+boot: 0.453
+risc-v: 0.440
+debug: 0.425
+register: 0.418
+arm: 0.418
+i386: 0.413
+socket: 0.409
+x86: 0.398
+TCG: 0.383
+files: 0.293
+assembly: 0.275
+hypervisor: 0.173
+KVM: 0.163
+
+mouse does not work in pass in
+Description of problem:
+I have this script to start qemu that passes in my mouse, keyboard and xbox controler. When I use it, it does not move the cursor(for my mouse) but the mouse is working because the hot corners do work. Moving my mouse in a up left direction in GNOME will show the menu and apps. Key board works, My controller works, and My mouse works, but the cursor does not move. Here is the script:
+Steps to reproduce:
+1. run the script above with the right variables.
+2. Move your mouse in the screen. It will not move the pointer.
+Additional information:
+I am using thees patches in qemu but it does not work in vanilla ether:
+https://lore.kernel.org/all/20241010182427.1434605-1-seanjc@google.com/
+
+and this in the kernel (6.14.0):
+https://github.com/torvalds/linux/commit/377b2f359d1f71c75f8cc352b5c81f2210312d83
+
+I am ruining qemu 10.0.0-rc1 (but 9.2.2 also does not work), kernel 6.14.0.
+
+I am runing mint on my host and arch on my guest. on my host I have virglrenderer on and on my guest I installed the pacman package lib32-vulkan-virtio and vulkan-virtio.
+
+If it helps I can remove the pass throws and insted use:
+
+-usbdevice tablet -usbdevice mouse -usbdevice keyboard
+or
+-device virtio-mouse -device virtio-keyboard -device virtio-tablet
diff --git a/results/classifier/zero-shot/118/peripherals/2928 b/results/classifier/zero-shot/118/peripherals/2928
new file mode 100644
index 00000000..5056a128
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2928
@@ -0,0 +1,86 @@
+peripherals: 0.819
+architecture: 0.754
+graphic: 0.737
+semantic: 0.611
+arm: 0.597
+device: 0.562
+PID: 0.533
+performance: 0.461
+risc-v: 0.451
+mistranslation: 0.449
+ppc: 0.445
+user-level: 0.439
+socket: 0.433
+vnc: 0.417
+TCG: 0.364
+permissions: 0.352
+x86: 0.344
+VMM: 0.328
+debug: 0.306
+kernel: 0.305
+register: 0.262
+boot: 0.258
+network: 0.220
+hypervisor: 0.191
+i386: 0.119
+virtual: 0.118
+KVM: 0.095
+assembly: 0.092
+files: 0.081
+
+Segmentation fault in most qemu-system commands on macOS ARM
+Description of problem:
+Most qemu-system binaries produce a segmentation fault:
+```
+raptor@fnord rust_os % qemu-system-x86_64
+zsh: segmentation fault  qemu-system-x86_64
+raptor@fnord rust_os % qemu-system-mips
+zsh: segmentation fault  qemu-system-mips
+raptor@fnord rust_os % qemu-system-sparc
+zsh: segmentation fault  qemu-system-sparc
+...
+```
+
+Some of them work properly:
+```
+raptor@fnord rust_os % qemu-system-aarch64
+qemu-system-aarch64: No machine specified, and there is no default
+Use -machine help to list supported machines
+raptor@fnord rust_os % qemu-system-arm
+qemu-system-arm: No machine specified, and there is no default
+Use -machine help to list supported machines
+raptor@fnord rust_os % qemu-system-avr
+qemu-system-avr: No machine specified, and there is no default
+Use -machine help to list supported machines
+...
+```
+Steps to reproduce:
+1. Install qemu via homebrew
+2. Run `qemu-system-x86_64`
+3. A segmentation fault error is produced
+Additional information:
+```
+raptor@fnord ~ % brew config
+HOMEBREW_VERSION: 4.4.32
+ORIGIN: https://github.com/Homebrew/brew
+HEAD: 12a3d4a6f1eedf483855716b989d828443438f79
+Last commit: 18 hours ago
+Branch: stable
+Core tap JSON: 23 Apr 08:36 UTC
+Core cask tap JSON: 23 Apr 08:36 UTC
+HOMEBREW_PREFIX: /opt/homebrew
+HOMEBREW_CASK_OPTS: []
+HOMEBREW_MAKE_JOBS: 8
+Homebrew Ruby: 3.3.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.8/bin/ruby
+CPU: octa-core 64-bit arm_ibiza
+Clang: 16.0.0 build 1600
+Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git
+Curl: 8.7.1 => /usr/bin/curl
+macOS: 15.3.2-arm64
+CLT: 16.2.0.0.1.1733547573
+Xcode: N/A
+Rosetta 2: false
+
+raptor@fnord ~ % brew doctor
+Your system is ready to brew.
+```
diff --git a/results/classifier/zero-shot/118/peripherals/2948 b/results/classifier/zero-shot/118/peripherals/2948
new file mode 100644
index 00000000..fbd67920
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2948
@@ -0,0 +1,43 @@
+peripherals: 0.932
+graphic: 0.928
+performance: 0.919
+device: 0.914
+semantic: 0.755
+permissions: 0.671
+PID: 0.667
+architecture: 0.651
+debug: 0.633
+boot: 0.594
+network: 0.567
+register: 0.513
+VMM: 0.511
+files: 0.508
+user-level: 0.502
+vnc: 0.452
+arm: 0.444
+assembly: 0.437
+risc-v: 0.374
+socket: 0.365
+ppc: 0.362
+virtual: 0.351
+mistranslation: 0.328
+kernel: 0.239
+TCG: 0.217
+hypervisor: 0.208
+i386: 0.127
+KVM: 0.101
+x86: 0.034
+
+-display sdl causes mice with relative movement to read garbage offsets
+Description of problem:
+`-device virtio-mouse` and `-device usb-mouse` (and probably other mice which send relative mouse movement data) are behaving incorrectly under linux guest and jitter a lot. In this specific case it only seems to happen with `-display sdl` as I could not reproduce this same issue with other of the following configurations: `-display gtk` and `-display spice-app` running with virt-viewer.
+This behavior is not present when running a Windows guest with the same configuration using `-display sdl`
+
+Another weird side note: this behavior is less apparent when running `evtest` on the exact mouse device having issues.
+
+![Video_2025-05-05_20-11-56](/uploads/589d74106d2e9bb5713234de451f5326/Video_2025-05-05_20-11-56.mp4)
+Steps to reproduce:
+1. Install guest operating system
+2. Install gnome metapackage and enable GDM
+3. Reboot
+4. The mouse shows jittery motion on the GDM screen.
diff --git a/results/classifier/zero-shot/118/peripherals/2976 b/results/classifier/zero-shot/118/peripherals/2976
new file mode 100644
index 00000000..eafb9e39
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/2976
@@ -0,0 +1,55 @@
+peripherals: 0.935
+device: 0.799
+performance: 0.791
+architecture: 0.672
+network: 0.636
+files: 0.618
+permissions: 0.559
+ppc: 0.520
+socket: 0.520
+kernel: 0.492
+vnc: 0.459
+semantic: 0.453
+graphic: 0.414
+virtual: 0.402
+risc-v: 0.391
+VMM: 0.388
+register: 0.382
+PID: 0.381
+hypervisor: 0.372
+i386: 0.342
+user-level: 0.336
+debug: 0.320
+x86: 0.317
+assembly: 0.235
+boot: 0.218
+arm: 0.173
+mistranslation: 0.169
+TCG: 0.150
+KVM: 0.071
+
+attach-ns doesn't work correctly in SR-IOV, cannot attach NS to VF if it is attached to a PF
+Description of problem:
+We can't attach namespace to a VF (Secondary controller) unless it is not attached to a primary controller first
+
+Lately in the commit https://github.com/qemu/qemu/commit/6ccca4b6bb9f994cc04e71004e1767a3476d2b23 the file qemu/hw/nvme/ctrl.c got changed -\> in function "nvme_ns_attachment" -\> line 6819 (At the time I'm writing the bug) which is the condation in attach ns to check if the namespace is attached "`if (nvme_ns(n, nsid)) {`"
+
+This change will always result in checking the namespace attach to the PF even if we are trying to attach it to the VF.
+Steps to reproduce:
+1. Enable a VF:
+
+```
+echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset
+sleep 1
+
+echo 2 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs
+sleep 1
+
+nvme virt-mgmt /dev/nvme0 -c 1 -r 1 -a 8 -n 1
+nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 8 -n 2
+nvme virt-mgmt /dev/nvme0 -c 1 -a 9
+sleep 1
+```
+
+2. attach namespace 1 to the PF (e.g. `vme attach-ns /dev/nvme0 -n1 -c0` )
+3. try to attach it using the nvme_cli command from the PF (e.g. `nvme attach-ns /dev/nvme0 -n1 -c1`)
diff --git a/results/classifier/zero-shot/118/peripherals/298 b/results/classifier/zero-shot/118/peripherals/298
new file mode 100644
index 00000000..197e6d2d
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/298
@@ -0,0 +1,31 @@
+peripherals: 0.952
+device: 0.845
+virtual: 0.813
+graphic: 0.791
+performance: 0.654
+boot: 0.485
+architecture: 0.347
+network: 0.239
+arm: 0.229
+user-level: 0.191
+mistranslation: 0.140
+semantic: 0.117
+assembly: 0.071
+vnc: 0.050
+VMM: 0.050
+permissions: 0.050
+risc-v: 0.033
+x86: 0.031
+ppc: 0.026
+debug: 0.023
+i386: 0.016
+files: 0.012
+register: 0.011
+TCG: 0.007
+PID: 0.007
+hypervisor: 0.006
+KVM: 0.005
+socket: 0.002
+kernel: 0.001
+
+OpenGL, Virtio-VGA, Virtio-GPU-PCI, GTK
diff --git a/results/classifier/zero-shot/118/peripherals/317 b/results/classifier/zero-shot/118/peripherals/317
new file mode 100644
index 00000000..e4ef82a9
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/317
@@ -0,0 +1,31 @@
+architecture: 0.952
+peripherals: 0.950
+device: 0.894
+network: 0.856
+arm: 0.847
+debug: 0.792
+kernel: 0.769
+socket: 0.731
+performance: 0.707
+vnc: 0.600
+risc-v: 0.517
+VMM: 0.514
+ppc: 0.509
+TCG: 0.476
+graphic: 0.471
+boot: 0.322
+files: 0.252
+PID: 0.232
+semantic: 0.187
+register: 0.170
+assembly: 0.143
+permissions: 0.140
+hypervisor: 0.082
+mistranslation: 0.052
+virtual: 0.051
+user-level: 0.034
+KVM: 0.009
+i386: 0.003
+x86: 0.003
+
+synchronous abort on accessing unused I/O ports on aarch64
diff --git a/results/classifier/zero-shot/118/peripherals/391 b/results/classifier/zero-shot/118/peripherals/391
new file mode 100644
index 00000000..d228842b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/391
@@ -0,0 +1,31 @@
+architecture: 0.952
+peripherals: 0.945
+device: 0.871
+network: 0.765
+ppc: 0.763
+performance: 0.700
+arm: 0.583
+graphic: 0.553
+TCG: 0.428
+PID: 0.421
+VMM: 0.379
+permissions: 0.376
+register: 0.363
+debug: 0.344
+risc-v: 0.330
+hypervisor: 0.293
+boot: 0.270
+x86: 0.267
+vnc: 0.260
+semantic: 0.240
+files: 0.221
+socket: 0.196
+virtual: 0.190
+mistranslation: 0.162
+assembly: 0.101
+user-level: 0.099
+kernel: 0.083
+i386: 0.017
+KVM: 0.009
+
+Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest
diff --git a/results/classifier/zero-shot/118/peripherals/446 b/results/classifier/zero-shot/118/peripherals/446
new file mode 100644
index 00000000..c2c8488c
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/446
@@ -0,0 +1,31 @@
+peripherals: 0.909
+device: 0.822
+performance: 0.550
+semantic: 0.443
+mistranslation: 0.422
+graphic: 0.388
+architecture: 0.360
+ppc: 0.282
+user-level: 0.263
+arm: 0.249
+assembly: 0.213
+PID: 0.201
+boot: 0.174
+socket: 0.148
+debug: 0.133
+virtual: 0.122
+permissions: 0.117
+files: 0.105
+vnc: 0.071
+register: 0.069
+network: 0.067
+TCG: 0.065
+VMM: 0.057
+i386: 0.055
+risc-v: 0.049
+x86: 0.024
+KVM: 0.011
+hypervisor: 0.010
+kernel: 0.007
+
+usb-audio does not work with Mac OS
diff --git a/results/classifier/zero-shot/118/peripherals/530 b/results/classifier/zero-shot/118/peripherals/530
new file mode 100644
index 00000000..44fecc1b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/530
@@ -0,0 +1,73 @@
+peripherals: 0.909
+graphic: 0.905
+boot: 0.889
+hypervisor: 0.864
+debug: 0.847
+arm: 0.841
+semantic: 0.836
+socket: 0.807
+risc-v: 0.800
+architecture: 0.798
+device: 0.790
+register: 0.781
+KVM: 0.773
+ppc: 0.766
+virtual: 0.758
+mistranslation: 0.751
+files: 0.743
+permissions: 0.736
+PID: 0.730
+performance: 0.727
+user-level: 0.719
+vnc: 0.699
+assembly: 0.697
+x86: 0.554
+i386: 0.548
+kernel: 0.495
+VMM: 0.491
+TCG: 0.491
+network: 0.467
+
+Invalid guest state when rebooting a nesting hypervisor
+Description of problem:
+On a standard Linux machine, I run a custom hypervisor stack based on [Hedron](https://github.com/cyberus-technology/hedron) in a qemu VM with nesting capabilities. The Hedron stack starts a nested Linux guest with complete pass-through of all resources not required for virtualizing the nested guest. In particular, ACPI and PCI including the reset functionality are directly accessible to the nested guest. As soon as the nested guest issues a machine reset, I get a hardware error with the following error message:
+
+<details><summary>KVM: entry failed, hardware error 0x80000021</summary>
+<pre>
+If you're running a guest on an Intel machine without unrestricted mode
+support, the failure can be most likely due to the guest entering an invalid
+state for Intel VT. For example, the guest maybe running in big real mode
+which is not supported on less recent Intel processors.
+
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=00050657
+ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
+EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 ffff0000 0000ffff 00009b00
+SS =0000 00000000 0000ffff 00009300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=003726f8
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+</pre>
+</details>
+
+If I'm not mistaken, the CR4 value of `0x003726f8` is the offending state here, because PCIDE (bit 17) is set, even though the arch state indicates real-mode and the Intel SDM states:
+
+> If the “IA-32e mode guest” VM-entry control is 0, bit 17 in the CR4 field (corresponding to CR4.PCIDE) must be 0.
+
+Furthermore, the issue is not present when not using PCID in the L1 hypervisor or when PCID/VPID are fused out using `qemu-kvm -cpu host,-pcid,-vmx-vpid,-vmx-invpcid-exit`.
+Steps to reproduce:
+1. Boot custom hypervisor stack (unfortunately not yet publicly available, I'm working on that)
+2. In nested Linux guest, type `reboot`, which eventually directly reboots the main VM (all main VM hardware is passed through to the single nested guest)
+Additional information:
+I have tracked down the [change](https://gitlab.com/qemu/qemu/-/commit/b16c0e20c74218f2d69710cedad11da7dd4d2190#063d8f78716c7a658841a1d51cc66bf30f697082_3920_3944) that likely introduced this issue. Moving the call to `kvm_put_sregs` back down (I suspect after `kvm_put_nested_state`, but I did not verify that yet) solves the reboot issue for me. The comment makes it clear that it is important to keep a certain order here, so I'm aware just reversing it is not an option.
+
+Maybe this already helps enough to figure out what exactly the issue and correct fix is, and I am happy to try any suggestions as long as I cannot provide a proper reproducer.
diff --git a/results/classifier/zero-shot/118/peripherals/545 b/results/classifier/zero-shot/118/peripherals/545
new file mode 100644
index 00000000..382836e8
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/545
@@ -0,0 +1,31 @@
+peripherals: 0.929
+mistranslation: 0.705
+architecture: 0.687
+graphic: 0.635
+performance: 0.474
+device: 0.400
+semantic: 0.329
+boot: 0.291
+debug: 0.146
+assembly: 0.133
+virtual: 0.112
+ppc: 0.103
+arm: 0.102
+hypervisor: 0.080
+user-level: 0.074
+VMM: 0.064
+i386: 0.055
+network: 0.050
+x86: 0.049
+register: 0.045
+TCG: 0.042
+PID: 0.038
+vnc: 0.037
+permissions: 0.033
+KVM: 0.021
+risc-v: 0.019
+files: 0.016
+socket: 0.016
+kernel: 0.009
+
+Abort in ohci_frame_boundary
diff --git a/results/classifier/zero-shot/118/peripherals/561 b/results/classifier/zero-shot/118/peripherals/561
new file mode 100644
index 00000000..70c2f85c
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/561
@@ -0,0 +1,31 @@
+peripherals: 0.991
+device: 0.855
+arm: 0.693
+architecture: 0.527
+graphic: 0.454
+ppc: 0.445
+debug: 0.402
+risc-v: 0.319
+boot: 0.302
+register: 0.233
+network: 0.230
+semantic: 0.214
+vnc: 0.188
+mistranslation: 0.141
+assembly: 0.111
+performance: 0.096
+user-level: 0.095
+socket: 0.094
+i386: 0.085
+VMM: 0.079
+hypervisor: 0.074
+TCG: 0.070
+virtual: 0.060
+permissions: 0.033
+KVM: 0.025
+PID: 0.024
+files: 0.021
+x86: 0.020
+kernel: 0.014
+
+Q35 - ACPI PCI hot-plug issue with Windows guest
diff --git a/results/classifier/zero-shot/118/peripherals/569 b/results/classifier/zero-shot/118/peripherals/569
new file mode 100644
index 00000000..11f66ff2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/569
@@ -0,0 +1,31 @@
+peripherals: 0.949
+device: 0.938
+debug: 0.882
+architecture: 0.862
+arm: 0.782
+performance: 0.754
+register: 0.535
+ppc: 0.499
+graphic: 0.469
+semantic: 0.412
+network: 0.386
+files: 0.376
+risc-v: 0.319
+mistranslation: 0.252
+permissions: 0.234
+user-level: 0.193
+vnc: 0.185
+boot: 0.174
+virtual: 0.107
+assembly: 0.095
+PID: 0.073
+VMM: 0.072
+socket: 0.051
+i386: 0.034
+hypervisor: 0.028
+TCG: 0.025
+x86: 0.007
+kernel: 0.005
+KVM: 0.005
+
+ESP SCSI adapter not working with DOS ASPI drivers
diff --git a/results/classifier/zero-shot/118/peripherals/56937788 b/results/classifier/zero-shot/118/peripherals/56937788
new file mode 100644
index 00000000..8e6150d2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/56937788
@@ -0,0 +1,369 @@
+peripherals: 0.807
+user-level: 0.794
+risc-v: 0.773
+hypervisor: 0.765
+TCG: 0.760
+KVM: 0.755
+vnc: 0.743
+mistranslation: 0.735
+VMM: 0.731
+virtual: 0.730
+ppc: 0.728
+debug: 0.723
+graphic: 0.720
+register: 0.706
+semantic: 0.705
+device: 0.697
+i386: 0.694
+x86: 0.693
+performance: 0.692
+permissions: 0.685
+files: 0.680
+arm: 0.665
+assembly: 0.638
+boot: 0.636
+network: 0.633
+architecture: 0.627
+PID: 0.620
+socket: 0.613
+kernel: 0.594
+
+[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
+
diff --git a/results/classifier/zero-shot/118/peripherals/585 b/results/classifier/zero-shot/118/peripherals/585
new file mode 100644
index 00000000..c22c328f
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/585
@@ -0,0 +1,31 @@
+peripherals: 0.862
+device: 0.829
+mistranslation: 0.764
+performance: 0.704
+arm: 0.698
+debug: 0.476
+architecture: 0.462
+risc-v: 0.436
+semantic: 0.405
+network: 0.382
+VMM: 0.338
+graphic: 0.320
+TCG: 0.319
+register: 0.291
+boot: 0.214
+i386: 0.193
+ppc: 0.178
+files: 0.165
+hypervisor: 0.156
+vnc: 0.152
+virtual: 0.136
+x86: 0.134
+socket: 0.117
+user-level: 0.094
+KVM: 0.092
+PID: 0.065
+assembly: 0.063
+kernel: 0.060
+permissions: 0.031
+
+mret trigger exception when pmp equals false
diff --git a/results/classifier/zero-shot/118/peripherals/588731 b/results/classifier/zero-shot/118/peripherals/588731
new file mode 100644
index 00000000..a4801874
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/588731
@@ -0,0 +1,184 @@
+peripherals: 0.847
+hypervisor: 0.823
+semantic: 0.790
+mistranslation: 0.786
+debug: 0.747
+assembly: 0.742
+register: 0.735
+graphic: 0.721
+virtual: 0.705
+permissions: 0.703
+arm: 0.702
+performance: 0.698
+device: 0.697
+ppc: 0.692
+TCG: 0.688
+risc-v: 0.680
+PID: 0.668
+architecture: 0.662
+socket: 0.659
+VMM: 0.634
+network: 0.625
+vnc: 0.622
+user-level: 0.617
+boot: 0.597
+i386: 0.587
+kernel: 0.527
+files: 0.500
+x86: 0.485
+KVM: 0.468
+
+PXE boot not working
+
+/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor
+
+
+
+net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
+ [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
+ DHCP (net0 02:5a:3b:27:00:a1)................ Connection timed out (0x4c106035)                                                            
+ No more network devices                                                                                                                    
+                                                                                                                                                                                                     
+No bootable device. 
+
+
+
+After doing a system_reset ....
+
+net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
+ [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
+DHCP (net0 02:5a:3b:27:00:a1).... ok                                                                                                       
+net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1                                                                                                   
+Booting from filename "boot.pxe"                                                                                                          
+tftp://x.x.x./boot.pxe.. ok      
+
+
+And it magaically works.
+
+using HEAD.
+
+I can't reproduce this.  I'm using:
+
+commit d9b73e47a3d596c5b33802597ec5bd91ef3348e2
+Author: Corentin Chary <email address hidden>
+Date:   Tue Jun 1 23:05:44 2010 +0200
+
+    vnc: add missing target for vnc-encodings-*.o
+
+I'm using the command:
+
+sudo x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=1024,telnet,server,nowait -monitor chardev:monitor
+
+The DHCP server I'm using is dnsmasq and it pxe boots as expected.  I've also confirmed that pxe boot is still functional after a system_reset.
+
+Please include information about the exact version of qemu that you are using and the DHCP server that is configured on your network.  Please also try to reproduce with the latest git.
+
+using latest git
+
+dhcp-3.0.1-58.EL4
+
+with configuration: 
+
+ host     xxxx  { filename "boot.pxe"; hardware ethernet 02:5A:3B:27:00:A1; fixed-address 10.201.1.161; }
+
+#
+## server config
+#
+server-identifier   a.b.c.d;
+server-name         "some-name";
+default-lease-time  600;
+max-lease-time      1200;
+ddns-update-style   ad-hoc;
+#log-facility        local6;
+
+allow booting;
+allow bootp;
+
+
+
+Latest GIT -> git clone http://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
+
+configured with options
+
+
+./configure --target-list=x86_64-softmmu --enable-gprof --enable-debug  --enable-linux-aio  --enable-profiler --with-kvm-trace 
+
+Install prefix    /usr/local
+BIOS directory    /usr/local/share/qemu
+binary directory  /usr/local/bin
+Manual directory  /usr/local/share/man
+ELF interp prefix /usr/gnemul/qemu-%M
+Source path       /root/qemu-test/qemu-kvm
+C compiler        gcc
+Host C compiler   gcc
+CFLAGS            -g
+QEMU_CFLAGS       -Werror -m64 -fstack-protector-all -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -W
+strict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
+LDFLAGS           -Wl,--warn-common -m64 -g
+make              make
+install           install
+host CPU          x86_64
+host big endian   no
+target list       x86_64-softmmu
+tcg debug enabled yes
+Mon debug enabled yes
+gprof enabled     yes
+sparse enabled    no
+strip binaries    no
+profiler          yes
+static build      no
+-Werror enabled   yes
+SDL support       yes
+curses support    yes
+curl support      yes
+check support     no
+mingw32 support   no
+Audio drivers     oss
+Extra audio cards ac97 es1370 sb16
+Block whitelist
+Mixer emulation   no
+VNC TLS support   yes
+VNC SASL support  yes
+xen support       no
+CPU emulation     yes
+brlapi support    no
+bluez  support    no
+Documentation     yes
+NPTL support      yes
+GUEST_BASE        yes
+PIE user targets  no
+vde support       no
+IO thread         no
+Linux AIO support yes
+Install blobs     yes
+KVM support       yes
+KVM PIT support   yes
+KVM device assig. yes
+KVM trace support yes
+fdt support       no
+preadv support    yes
+fdatasync         yes
+uuid support      yes
+vhost-net support yes
+
+
+
+The same to me, but rarely it does start only from third attempt
+
+There seems to be an issue with kvm virtual network interface being connected to a in-kernel bridge implementation.
+
+When you configure networking that way the bridge port comes up when the kvm instance is started.
+
+As the time from the kvm start to entering the netboot rom is minimal and the timeout before the bridge starts forwarding on new ports is long this may cause the machine never getting an address.
+
+If you are using a bridge try setting the forwarding delay to a small value like:
+
+iface vmbridge inet static
+ bridge_ports <probably should put some network interface name here - undocumented>
+ address 10.10.10.1
+ netmask 255.255.255.0
+ post-up brctl setfd vmbridge 3
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/595 b/results/classifier/zero-shot/118/peripherals/595
new file mode 100644
index 00000000..ad04333b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/595
@@ -0,0 +1,41 @@
+peripherals: 0.950
+performance: 0.926
+graphic: 0.905
+device: 0.885
+vnc: 0.823
+architecture: 0.773
+semantic: 0.729
+network: 0.687
+ppc: 0.686
+PID: 0.633
+register: 0.593
+permissions: 0.581
+mistranslation: 0.561
+arm: 0.546
+socket: 0.474
+VMM: 0.435
+debug: 0.425
+risc-v: 0.415
+boot: 0.357
+user-level: 0.348
+files: 0.335
+assembly: 0.318
+TCG: 0.260
+kernel: 0.251
+i386: 0.156
+virtual: 0.138
+hypervisor: 0.102
+x86: 0.059
+KVM: 0.018
+
+QEMU VNC mouse doesn't move in tablet mode os9
+Description of problem:
+What I am trying to do is have a headless os9 running in QEMU on ubuntu and use the native vnc support in QEMU to access the screen. That is setup and works as expected but the mouse only works in ps/2 mode and that is clearly very undesirable (mouse is never lined up). I set it up in tablet mode and when I am in the QEMU window on the host the mouse works perfect (I added tablet mode to os9 with: https://github.com/kanjitalk755/macos9-usb-tablet). That same tablet mode results in the mouse not moving at all over vnc, if I ctrl+alt 2 and switch the mouse type from tablet mode it starts working again but not lined up at all as expected, cant get to any buttons on edges. Is there anyone in here that ran into this? Am I the only one using QEMU VNC?
+
+Iv thought about running a vnc application on the vm itself but performance was meh at best. Any tips would be worth a lot to me, its a sin to say but I am trying to adapt this into a production environment...
+
+Upon further investigation this seems to be a issue on Linux. I am testing the QEMU on windows and its working as expected over VNC. That is to say if QEMU is running on a windows host, it just works over vnc with tablet mode. So what could be causing Linux version to not work? I did compile it from source, are there any configure flags I am missing? I am trying to run it on Ubuntu server 21.04
+Steps to reproduce:
+1.add vnc option to parameters
+2.enable tablet mode and install driver in os9
+3.connect to vnc and mouse doesn't move
diff --git a/results/classifier/zero-shot/118/peripherals/60339453 b/results/classifier/zero-shot/118/peripherals/60339453
new file mode 100644
index 00000000..7862d43c
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/60339453
@@ -0,0 +1,86 @@
+peripherals: 0.824
+kernel: 0.805
+register: 0.787
+boot: 0.782
+arm: 0.780
+performance: 0.764
+permissions: 0.750
+TCG: 0.748
+VMM: 0.712
+risc-v: 0.707
+device: 0.706
+mistranslation: 0.699
+hypervisor: 0.697
+PID: 0.685
+network: 0.682
+vnc: 0.680
+debug: 0.672
+graphic: 0.671
+KVM: 0.669
+user-level: 0.663
+semantic: 0.662
+architecture: 0.649
+x86: 0.647
+virtual: 0.630
+files: 0.623
+ppc: 0.615
+socket: 0.607
+i386: 0.533
+assembly: 0.486
+
+[BUG] scsi: vmw_pvscsi: Boot hangs during scsi under qemu, post commit e662502b3a78
+
+Hi,
+
+Commit e662502b3a78 ("scsi: vmw_pvscsi: Set correct residual data length"),
+and its backports to stable trees, makes kernel hang during boot, when
+ran as a VM under qemu with following parameters:
+
+  -drive file=$DISKFILE,if=none,id=sda
+  -device pvscsi
+  -device scsi-hd,bus=scsi.0,drive=sda
+
+Diving deeper, commit e662502b3a78
+
+  @@ -585,7 +585,13 @@ static void pvscsi_complete_request(struct 
+pvscsi_adapter *adapter,
+                case BTSTAT_SUCCESS:
+  +                     /*
+  +                      * Commands like INQUIRY may transfer less data than
+  +                      * requested by the initiator via bufflen. Set residual
+  +                      * count to make upper layer aware of the actual amount
+  +                      * of data returned.
+  +                      */
+  +                     scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen);
+
+assumes 'e->dataLen' is properly armed with actual num of bytes
+transferred; alas qemu's hw/scsi/vmw_pvscsi.c never arms the 'dataLen'
+field of the completion descriptor (kept zero).
+
+As a result, the residual count is set as the *entire* 'scsi_bufflen' of a
+good transfer, which makes upper scsi layers repeatedly ignore this
+valid transfer.
+
+Not properly arming 'dataLen' seems as an oversight in qemu, which needs
+to be fixed.
+
+However, since kernels with commit e662502b3a78 (and backports) now fail
+to boot under qemu's "-device pvscsi", a suggested workaround is to set
+the residual count *only* if 'e->dataLen' is armed, e.g:
+
+  @@ -588,7 +588,8 @@ static void pvscsi_complete_request(struct pvscsi_adapter 
+*adapter,
+                           * count to make upper layer aware of the actual 
+amount
+                           * of data returned.
+                           */
+  -                       scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen);
+  +                       if (e->dataLen)
+  +                               scsi_set_resid(cmd, scsi_bufflen(cmd) - 
+e->dataLen);
+
+in order to make kernels boot on old qemu binaries.
+
+Best,
+Shmulik
+
diff --git a/results/classifier/zero-shot/118/peripherals/612297 b/results/classifier/zero-shot/118/peripherals/612297
new file mode 100644
index 00000000..f7c5681c
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/612297
@@ -0,0 +1,48 @@
+peripherals: 0.920
+KVM: 0.879
+mistranslation: 0.867
+user-level: 0.775
+device: 0.766
+graphic: 0.763
+x86: 0.715
+network: 0.712
+semantic: 0.707
+boot: 0.684
+architecture: 0.665
+ppc: 0.632
+performance: 0.584
+socket: 0.494
+virtual: 0.487
+kernel: 0.429
+assembly: 0.428
+permissions: 0.397
+PID: 0.362
+hypervisor: 0.356
+vnc: 0.308
+register: 0.308
+VMM: 0.289
+files: 0.258
+debug: 0.249
+arm: 0.201
+risc-v: 0.197
+i386: 0.171
+TCG: 0.140
+
+qemu-kvm fails to detect mouse while Windows 95 setup
+
+CPU: AMD Phenom II X4 945
+KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package)
+Kernel: linux-2.6.26.8-rt16
+arch: x86_64
+Guest: Windows 95 B
+
+I'm trying to install Windows 95 B on qemu-kvm with this options:
+
+kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M -rtc base=localtime -k de -soundhw sb16 -vga cirrus -net user,hostname=w95vm -net nic,model=ne2k_pci -boot a -fda /var/mmn/vm/floppy/win95B_Drive-D-boot.img -cdrom /var/mmn/vm/CD/win95-setup.iso -no-acpi -no-kvm -usb
+
+I've also tried some other option, but always the same: no ps/2 mouse detection. And usb mouse is not supported by Windows 95 B while setup process. This is only possible later by installing the extension usbsupp.exe after the system setup.
+
+Seems like you were using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks!
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/615 b/results/classifier/zero-shot/118/peripherals/615
new file mode 100644
index 00000000..765f25d4
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/615
@@ -0,0 +1,40 @@
+peripherals: 0.912
+device: 0.885
+graphic: 0.665
+semantic: 0.434
+performance: 0.422
+virtual: 0.377
+PID: 0.373
+arm: 0.369
+network: 0.349
+vnc: 0.347
+VMM: 0.342
+debug: 0.320
+risc-v: 0.312
+mistranslation: 0.241
+TCG: 0.232
+i386: 0.212
+boot: 0.209
+ppc: 0.203
+socket: 0.152
+user-level: 0.138
+register: 0.125
+architecture: 0.098
+x86: 0.090
+permissions: 0.085
+files: 0.070
+kernel: 0.045
+hypervisor: 0.044
+assembly: 0.017
+KVM: 0.001
+
+Not sure if this is a qemu issue but SD card is not correctly read. blk_update_request: I/O error on Manjaro libvirt OS.
+Description of problem:
+
+Steps to reproduce:
+1. Run vagrant command line 
+2. Start console in virt-manager
+3. Add USB SD card reader device with SD card.
+4. Go back to console
+Additional information:
+I've bought a new SD card reader and SD card, tried it on other ports and the problem persists.
diff --git a/results/classifier/zero-shot/118/peripherals/629 b/results/classifier/zero-shot/118/peripherals/629
new file mode 100644
index 00000000..817dd346
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/629
@@ -0,0 +1,40 @@
+peripherals: 0.890
+graphic: 0.875
+device: 0.767
+boot: 0.638
+architecture: 0.635
+semantic: 0.499
+permissions: 0.428
+socket: 0.419
+performance: 0.374
+debug: 0.336
+files: 0.286
+kernel: 0.285
+i386: 0.278
+register: 0.241
+arm: 0.241
+x86: 0.210
+PID: 0.204
+network: 0.172
+mistranslation: 0.170
+vnc: 0.154
+ppc: 0.152
+assembly: 0.143
+user-level: 0.121
+risc-v: 0.084
+virtual: 0.080
+hypervisor: 0.069
+TCG: 0.039
+VMM: 0.039
+KVM: 0.023
+
+Trying to use EGA or VGA functions from QBASIC doesn't work
+Description of problem:
+QBASIC can't start any graphics mode beyond CGA
+
+Some other programs that default to EGA crash trying to start graphics; none that I've tried can start EGA at all; believe to be the same bug; will file separately if it turns out to not be
+Steps to reproduce:
+1. Boot
+2. Start QBASIC
+3. Run a program consisting of only "SCREEN 12" for VGA or "SCREEN 9" for EGA
+4. Get error message "Illegal Function Call"
diff --git a/results/classifier/zero-shot/118/peripherals/641 b/results/classifier/zero-shot/118/peripherals/641
new file mode 100644
index 00000000..17e37608
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/641
@@ -0,0 +1,31 @@
+peripherals: 0.903
+device: 0.813
+performance: 0.765
+network: 0.755
+socket: 0.657
+kernel: 0.647
+arm: 0.574
+TCG: 0.569
+architecture: 0.548
+vnc: 0.540
+risc-v: 0.517
+VMM: 0.507
+register: 0.505
+files: 0.473
+PID: 0.468
+ppc: 0.408
+permissions: 0.404
+debug: 0.366
+graphic: 0.355
+hypervisor: 0.338
+boot: 0.337
+KVM: 0.279
+semantic: 0.254
+assembly: 0.197
+virtual: 0.197
+x86: 0.166
+mistranslation: 0.103
+user-level: 0.093
+i386: 0.092
+
+6.1.0 introduces regression in q35, unable to add more than 15 pcie-root-ports
diff --git a/results/classifier/zero-shot/118/peripherals/651 b/results/classifier/zero-shot/118/peripherals/651
new file mode 100644
index 00000000..1faf476e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/651
@@ -0,0 +1,31 @@
+peripherals: 0.961
+architecture: 0.959
+ppc: 0.951
+device: 0.935
+register: 0.894
+boot: 0.823
+debug: 0.649
+performance: 0.617
+PID: 0.554
+mistranslation: 0.529
+graphic: 0.528
+permissions: 0.473
+files: 0.346
+TCG: 0.322
+vnc: 0.263
+VMM: 0.215
+semantic: 0.211
+user-level: 0.173
+socket: 0.143
+virtual: 0.118
+risc-v: 0.097
+assembly: 0.028
+network: 0.020
+i386: 0.020
+kernel: 0.013
+hypervisor: 0.011
+arm: 0.009
+KVM: 0.007
+x86: 0.001
+
+powerpc: Starting machine ref405ep fails with "Could not load PowerPC BIOS 'ppc405_rom.bin'"
diff --git a/results/classifier/zero-shot/118/peripherals/685 b/results/classifier/zero-shot/118/peripherals/685
new file mode 100644
index 00000000..55e748d1
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/685
@@ -0,0 +1,99 @@
+peripherals: 0.927
+VMM: 0.884
+TCG: 0.882
+vnc: 0.871
+permissions: 0.866
+arm: 0.838
+semantic: 0.811
+socket: 0.810
+ppc: 0.798
+virtual: 0.792
+device: 0.787
+architecture: 0.771
+PID: 0.764
+graphic: 0.758
+assembly: 0.757
+performance: 0.749
+risc-v: 0.742
+hypervisor: 0.739
+KVM: 0.733
+register: 0.727
+debug: 0.717
+x86: 0.708
+boot: 0.701
+i386: 0.690
+kernel: 0.577
+files: 0.551
+user-level: 0.519
+network: 0.490
+mistranslation: 0.468
+
+QEMU Segmentation fault - Xen / Ubuntu 18.04
+Description of problem:
+See notes below.
+Steps to reproduce:
+See notes below.
+Additional information:
+* The error is very rare.
+* The VMs have been created with `xl create` (Xen utility).
+* The error has been found with _coredump_ ([core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4](/uploads/a90e21a2e14c9ebba07585034de25b1a/core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4)):
+```bash
+$ sudo coredumpctl info 16892
+           PID: 16892 (qemu-system-i38)
+           UID: 0 (root)                               
+           GID: 0 (root)                                                                                                                                                                                                                      
+        Signal: 11 (SEGV)                
+     Timestamp: Thu 2021-10-21 11:51:07 MSK (17min ago)           
+  Command Line: /usr/bin/qemu-system-i386 -xen-domid 2679 -no-shutdown -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-2679,server,nowait -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp
+    Executable: /usr/bin/qemu-system-i386
+ Control Group: /system.slice/ptms.sandbox.sandbox-creator.service
+          Unit: ptms.sandbox.sandbox-creator.service
+         Slice: system.slice
+       Boot ID: abb1047980ee4143937dcce7b8da9e60                                                                            
+    Machine ID: bdce82649a9d4d9db192a692b330943f                      
+      Hostname: ptms-7
+       Storage: /var/lib/systemd/coredump/core.qemu-system-i38.0.abb1047980ee4143937dcce7b8da9e60.16892.1634806267000000.lz4
+       Message: Process 16892 (qemu-system-i38) of user 0 dumped core.         
+                                                                           
+                Stack trace of thread 16892:                 
+                #0  0x00007f1c6d33ca5f __memmove_avx_unaligned_erms (libc.so.6)
+                #1  0x00005586abeae8bf iov_from_buf_full (qemu-system-i386)
+                #2  0x00005586abe03d46 n/a (qemu-system-i386)
+                #3  0x00005586abdd17ad n/a (qemu-system-i386)
+                #4  0x00005586abeac93c n/a (qemu-system-i386)        
+                #5  0x00007f1c6d2067b0 n/a (libc.so.6)                
+                #6  0x00005586abeb89bd n/a (qemu-system-i386)
+                #7  0x00005586abeaaf87 aio_bh_poll (qemu-system-i386)            
+                #8  0x00005586abe9a45e aio_dispatch (qemu-system-i386)  
+                #9  0x00005586abeaad9e n/a (qemu-system-i386)           
+                #10 0x00007f1c6fd7f537 g_main_context_dispatch (libglib-2.0.so.0)
+                #11 0x00005586abeb5caa main_loop_wait (qemu-system-i386)
+                #12 0x00005586abca092d qemu_main_loop (qemu-system-i386)
+                #13 0x00005586ab9f508e main (qemu-system-i386)
+                #14 0x00007f1c6d1cfbf7 __libc_start_main (libc.so.6)
+                #15 0x00005586ab9f97fa _start (qemu-system-i386)
+                                                                         
+                Stack trace of thread 16932:                 
+                #0  0x00007f1c6d2c9639 syscall (libc.so.6)   
+                #1  0x00005586abe9de1b qemu_event_wait (qemu-system-i386)
+                #2  0x00005586abea5e28 n/a (qemu-system-i386)
+                #3  0x00005586abe9d0b6 n/a (qemu-system-i386)
+                #4  0x00007f1c6d5a66db start_thread (libpthread.so.0)
+                #5  0x00007f1c6d2cf71f __clone (libc.so.6)          
+                                                               
+                Stack trace of thread 16957:                   
+                #0  0x00007f1c6d5b0474 __libc_read (libpthread.so.0)
+                #1  0x00007f1c71f67777 n/a (libxenstore.so.3.0)      
+                #2  0x00007f1c71f6784d n/a (libxenstore.so.3.0)
+                #3  0x00007f1c71f67b61 n/a (libxenstore.so.3.0)
+                #4  0x00007f1c6d5a66db start_thread (libpthread.so.0)
+                #5  0x00007f1c6d2cf71f __clone (libc.so.6)          
+
+                Stack trace of thread 16958:                   
+                #0  0x00007f1c6d5b0474 __libc_read (libpthread.so.0)
+                #1  0x00007f1c71f67777 n/a (libxenstore.so.3.0)      
+                #2  0x00007f1c71f6784d n/a (libxenstore.so.3.0)
+                #3  0x00007f1c71f67b61 n/a (libxenstore.so.3.0)
+                #4  0x00007f1c6d5a66db start_thread (libpthread.so.0)
+                #5  0x00007f1c6d2cf71f __clone (libc.so.6)
+```
diff --git a/results/classifier/zero-shot/118/peripherals/752 b/results/classifier/zero-shot/118/peripherals/752
new file mode 100644
index 00000000..be421d4e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/752
@@ -0,0 +1,43 @@
+peripherals: 0.931
+device: 0.930
+graphic: 0.821
+VMM: 0.717
+debug: 0.664
+performance: 0.643
+semantic: 0.638
+arm: 0.538
+architecture: 0.522
+vnc: 0.503
+register: 0.493
+PID: 0.465
+virtual: 0.412
+risc-v: 0.378
+permissions: 0.370
+socket: 0.368
+boot: 0.346
+kernel: 0.263
+mistranslation: 0.261
+network: 0.248
+ppc: 0.229
+hypervisor: 0.228
+TCG: 0.183
+user-level: 0.156
+x86: 0.136
+assembly: 0.113
+i386: 0.108
+files: 0.053
+KVM: 0.032
+
+vmmouse device gets attached twice, one without i8042 associated
+Description of problem:
+I'm developing [a driver for the VMware mouse device](https://github.com/NattyNarwhal/vmwmouse). I know this works properly on VMware, but I'm trying it in QEMU too.
+
+[My full notes](https://github.com/NattyNarwhal/vmwmouse/issues/1), but most relevant is:
+
+* a vmmouse instance gets initialized twice (confirmed in qtree), one with i8042 the first time, one without the second time
+* the second vmmouse instance is the one receiving the events, passing them to the i8042 device's fake event handler
+* obviously, a crash because ISAKBDDevice should never be null
+Steps to reproduce:
+1. Load VMware mouse driver
+2. Move cursor (I recommend waiting until Windows loads before doing so, it is very easy to corrupt the guest filesystem if you do it while Windows is loading)
+3. Crash
diff --git a/results/classifier/zero-shot/118/peripherals/754635 b/results/classifier/zero-shot/118/peripherals/754635
new file mode 100644
index 00000000..e889dbc9
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/754635
@@ -0,0 +1,100 @@
+peripherals: 0.952
+semantic: 0.926
+graphic: 0.919
+device: 0.919
+user-level: 0.918
+debug: 0.918
+architecture: 0.893
+risc-v: 0.879
+socket: 0.876
+PID: 0.873
+arm: 0.869
+i386: 0.866
+performance: 0.854
+register: 0.842
+mistranslation: 0.834
+hypervisor: 0.831
+kernel: 0.827
+virtual: 0.822
+permissions: 0.821
+files: 0.817
+assembly: 0.810
+network: 0.802
+VMM: 0.789
+boot: 0.750
+TCG: 0.739
+KVM: 0.737
+vnc: 0.726
+x86: 0.710
+ppc: 0.702
+
+-d option outs wrong info about sections
+
+For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file:
+$ cat /tmp/qemu.log | grep -A7 guest
+Relocating guest address space from 0x08048000 to 0x8048000
+guest_base  0x0
+start    end      size     prot
+00048000-0005f000 00017000 r-x
+0005f000-00069000 0000a000 rw-
+00040000-00041000 00001000 ---
+00041000-00041800 00000800 rw-
+00041800-0005d800 0001c000 r-x
+0005d800-0005f800 00002000 rw-
+
+But such command in 0.12.5 release outs this:
+$ cat /tmp/qemu.log | grep -A7 guest
+guest_base  0x0
+start    end      size     prot
+00f38000-00f39000 00001000 ---
+08048000-0805f000 00017000 r-x
+0805f000-08061000 00002000 rw-
+40000000-40080000 00080000 rw-
+40080000-40081000 00001000 ---
+40081000-4009d000 0001c000 r-x
+
+It looks correct.
+I received such differences and with qemu-microblaze. 
+
+After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c:
+in 0.12.5:
+end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS);
+
+in 0.14.0:
+int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,
+
+V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22
+
+I make this changes:
+$ diff -up qemu-0.14.0/exec.c exec.c
+--- qemu-0.14.0/exec.c	2011-04-08 17:26:00.524464002 +0400
++++ exec.c	2011-04-08 17:26:09.800464003 +0400
+@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk
+     data.prot = 0;
+ 
+     for (i = 0; i < V_L1_SIZE; i++) {
+-        int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,
++        int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS),
+                                        V_L1_SHIFT / L2_BITS - 1, l1_map + i);
+         if (rc != 0) {
+             return rc;
+
+After this outputs looks correct. 
+
+I don't know code base good, and think what may to do more general corrections.
+Host system: linux i386
+
+Hi,
+
+Thanks for reporting this issue, and the investigation. I don't really understand the rationale for the change, so I can't help much.
+
+This change appears to be from 5cd2c5b6ad75c46d40118ac67c0c09d4e7930a65. I think input from Richard Henderson (the author of the change) would be very useful.
+
+Brad
+
+
+Looking through old bug tickets... is this still an 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/zero-shot/118/peripherals/795866 b/results/classifier/zero-shot/118/peripherals/795866
new file mode 100644
index 00000000..6c85e005
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/795866
@@ -0,0 +1,184 @@
+peripherals: 0.891
+hypervisor: 0.862
+mistranslation: 0.858
+user-level: 0.851
+register: 0.821
+risc-v: 0.813
+assembly: 0.802
+performance: 0.799
+TCG: 0.799
+debug: 0.788
+semantic: 0.779
+permissions: 0.776
+vnc: 0.774
+arm: 0.761
+virtual: 0.757
+graphic: 0.757
+ppc: 0.754
+x86: 0.743
+PID: 0.735
+device: 0.729
+i386: 0.725
+VMM: 0.721
+KVM: 0.721
+architecture: 0.714
+kernel: 0.703
+files: 0.701
+boot: 0.681
+socket: 0.680
+network: 0.665
+
+pci passthrough doesn´t work
+
+Hi all,
+
+I have some problems passing through a pci device to kvm guest.
+First I have to say that I´m using the latest kvm-kernel und qemu-kvm from git-tree (Date 11.06.2011).
+
+I want´t to passthrough this device to guest:
+
+lspci-output:
+
+02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01)
+
+So at first I have bind the driver to psi-stub:
+
+modprobe -r kvm-intel
+modprobe -r kvm
+echo "18c3 0720" > /sys/bus/pci/drivers/pci-stub/new_id
+echo 0000:02:00.0  > /sys/bus/pci/devices/0000:02:00.0/driver/unbind
+echo 0000:02:00.0  > /sys/bus/pci/drivers/pci-stub/bind
+modprobe kvm
+modprobe kvm-intel
+
+Then I have assigned device to guest:
+-device pci-assign,host=02:00.0
+
+When I start the guest. The device succesfully get´s an msi-IRQ on host-system:
+
+cat /proc/interrupt output:
+
+ 32:          0          0          0          0   PCI-MSI-edge      kvm_assigned_msi_device
+
+
+On guest device is visibel:
+
+lspci output:
+00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01)
+
+
+Sometimes the device (on guest) get´s an IRQ between 10-16:
+
+00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01)
+        Subsystem: Micronas Semiconductor Holding AG Device dd00
+        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
+        Interrupt: pin A routed to IRQ 11
+        Region 0: Memory at f2050000 (32-bit, non-prefetchable) [size=64K]
+        Region 1: Memory at f2060000 (32-bit, non-prefetchable) [size=64K]
+        Capabilities: [58] Express (v1) Endpoint, MSI 00
+                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
+                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
+                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
+                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
+                        MaxPayload 128 bytes, MaxReadReq 128 bytes
+                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
+                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited
+                        ClockPM- Suprise- LLActRep- BwNot-
+                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
+                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
+                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
+        Capabilities: [40] Power Management version 2
+                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
+        Capabilities: [48] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
+                Address: 00000000  Data: 0000
+        Kernel modules: ngene
+
+
+In this case the kernel-modul (ngene) can not access the device:
+
+dmesg | grep ngene
+
+[   69.977900] ngene 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, high) -> IRQ 11
+[   69.977909] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
+[   69.978962] ngene 0000:00:05.0: setting latency timer to 64
+[   69.979118] ngene: Device version 1
+[   69.979129] ngene 0000:00:05.0: firmware: requesting ngene_18.fw
+[   69.980884] ngene: Loading firmware file ngene_18.fw.
+[   71.981052] ngene: Command timeout cmd=01 prev=00
+[   71.981205] host_to_ngene (c000): 01 00 00 00 00 00 00 00
+[   71.981457] ngene_to_host (c100): 00 00 00 00 00 00 00 00
+[   71.981704] dev->hosttongene (ec902000): 01 00 00 00 00 00 00 00
+[   71.981963] dev->ngenetohost (ec902100): 00 00 00 00 00 00 00 00
+[   73.985111] ngene: Command timeout cmd=02 prev=00
+[   73.985415] host_to_ngene (c000): 02 04 00 d0 00 04 00 00
+[   73.985684] ngene_to_host (c100): 00 00 00 00 00 00 00 00
+[   73.985931] dev->hosttongene (ec902000): 02 04 00 d0 00 04 00 00
+[   73.986191] dev->ngenetohost (ec902100): 00 00 00 00 00 00 00 00
+[   73.986568] ngene 0000:00:05.0: PCI INT A disabled
+[   73.986584] ngene: probe of 0000:00:05.0 failed with error -1
+
+
+Sometimes the device (on guest) gets an msi-irq f. e. IRQ 29.
+Then kernel-modul (ngene) can succesfully load the driver and all works fine.
+
+
+Short to say:
+
+HOST 	GUEST		STATUS
+MSI-IRQ	MSI-IRQ		ALL FINE
+MSI-IRQ IOAPIC-IRQ	DOESN´t WORK
+
+with modinfo I had a look at the kernel-modul if there is way to force msi, but without success.
+
+But I think IRQ between (10-16) should also work because when I load the kernel-modul on host with IRQ (10-16)
+it works. (Device only get´s an MSI-IRQ If I start the vm to passthrough)
+
+Do anyone know where can be the problem?
+
+Here is the dmesg - output of second device which is currently working on guest with MSI-IRQ 29:
+
+[    2.137175] ngene 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, high) -> IRQ 11
+[    2.137183] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
+[    2.140506] ngene 0000:00:04.0: setting latency timer to 64
+[    2.140679] ngene: Device version 1
+[    2.140693] ngene 0000:00:04.0: firmware: requesting ngene_18.fw
+[    2.214848] ngene: Loading firmware file ngene_18.fw.
+[    2.249797] ngene 0000:00:04.0: irq 29 for MSI/MSI-X
+
+
+
+
+lspci - output on guest:
+
+00:04.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01)
+        Subsystem: Micronas Semiconductor Holding AG Device dd00
+        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
+        Latency: 0, Cache Line Size: 64 bytes
+        Interrupt: pin A routed to IRQ 29
+        Region 0: Memory at f2030000 (32-bit, non-prefetchable) [size=64K]
+        Region 1: Memory at f2040000 (32-bit, non-prefetchable) [size=64K]
+        Capabilities: <access denied>
+        Kernel driver in use: ngene
+        Kernel modules: ngene
+
+00:05.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01)
+        Subsystem: Micronas Semiconductor Holding AG Device dd00
+        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
+        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
+        Interrupt: pin A routed to IRQ 11
+        Region 0: Memory at f2050000 (32-bit, non-prefetchable) [size=64K]
+        Region 1: Memory at f2060000 (32-bit, non-prefetchable) [size=64K]
+        Capabilities: <access denied>
+        Kernel modules: ngene
+
+
+IRQ 11 not working.
+IRQ 29 working
+
+Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU? Or can we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/813546 b/results/classifier/zero-shot/118/peripherals/813546
new file mode 100644
index 00000000..e9009796
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/813546
@@ -0,0 +1,46 @@
+peripherals: 0.932
+graphic: 0.844
+device: 0.831
+semantic: 0.685
+register: 0.656
+performance: 0.625
+mistranslation: 0.619
+ppc: 0.607
+user-level: 0.579
+network: 0.548
+risc-v: 0.529
+VMM: 0.529
+socket: 0.507
+vnc: 0.500
+kernel: 0.494
+debug: 0.482
+architecture: 0.478
+permissions: 0.473
+virtual: 0.433
+PID: 0.433
+assembly: 0.420
+boot: 0.420
+arm: 0.418
+i386: 0.408
+hypervisor: 0.391
+KVM: 0.385
+x86: 0.382
+files: 0.373
+TCG: 0.368
+
+option to disable PS/2 mouse
+
+Adds an option to disable the PS/2 mouse.
+
+This is useful to work around bugs in PS/2 drivers in some system or testing system without a PS/2 mouse present.
+
+
+
+Sorry, we don't take any patches from the bug tracker... Could you please post patches on the qemu-devel mailing list instead? Thanks!
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/830 b/results/classifier/zero-shot/118/peripherals/830
new file mode 100644
index 00000000..b4be26e2
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/830
@@ -0,0 +1,31 @@
+architecture: 0.980
+peripherals: 0.935
+device: 0.800
+arm: 0.702
+graphic: 0.326
+performance: 0.326
+boot: 0.310
+debug: 0.285
+semantic: 0.278
+virtual: 0.275
+network: 0.256
+risc-v: 0.206
+vnc: 0.174
+register: 0.168
+mistranslation: 0.162
+PID: 0.139
+permissions: 0.138
+hypervisor: 0.131
+ppc: 0.130
+files: 0.110
+TCG: 0.091
+assembly: 0.056
+user-level: 0.046
+VMM: 0.040
+socket: 0.030
+kernel: 0.018
+KVM: 0.017
+x86: 0.007
+i386: 0.002
+
+QEMU aarch64 support for Windows TPM driver (TIS, CRB interfaces)
diff --git a/results/classifier/zero-shot/118/peripherals/863 b/results/classifier/zero-shot/118/peripherals/863
new file mode 100644
index 00000000..e0c23bc5
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/863
@@ -0,0 +1,84 @@
+peripherals: 0.806
+graphic: 0.773
+arm: 0.717
+permissions: 0.687
+semantic: 0.686
+architecture: 0.674
+PID: 0.674
+risc-v: 0.644
+ppc: 0.637
+TCG: 0.617
+performance: 0.615
+register: 0.605
+virtual: 0.582
+hypervisor: 0.581
+device: 0.573
+mistranslation: 0.555
+debug: 0.523
+user-level: 0.489
+assembly: 0.482
+vnc: 0.481
+VMM: 0.460
+boot: 0.413
+kernel: 0.393
+socket: 0.389
+files: 0.368
+network: 0.320
+x86: 0.273
+KVM: 0.238
+i386: 0.137
+
+contrib/plugins/howvec.c for ARM64 under constrained
+Description of problem:
+Consider the static InsnClassExecCount aarch64_insn_classes array in contrib/plugins/howvec.c There are 5 entries which will never be discovered, and so count as 0; see the dump below.
+
+I did not figure out which of prior rows in the table was over-eagerly getting instructions intended for the subsequent counted-as-0 row.
+
+```
+        udef aka                 UDEF        65536
+         sve aka                  SVE    268435456
+         res aka             Reserved    268369920
+       pcrel aka           PCrel addr    134217728
+        asit aka   Add/Sub (imm,tags)     67108864
+         asi aka        Add/Sub (imm)     67108864
+        logi aka        Logical (imm)     67108864
+       movwi aka      Move Wide (imm)     67108864
+        bitf aka             Bitfield     67108864
+        extr aka              Extract     67108864
+        dpri aka        Data Proc Imm            0
+        cndb aka    Cond Branch (imm)     33554432
+        excp aka        Exception Gen     16777216
+         nop aka                  NOP            1
+        hint aka                Hints         4095
+        barr aka             Barriers         4096
+        psta aka               PSTATE        32768
+        sins aka          System Insn      1048576
+        sreg aka           System Reg      2097152
+        breg aka         Branch (reg)     33554432
+        bimm aka         Branch (imm)    134217728
+        cmpb aka         Cmp & Branch     67108864
+        tstb aka         Tst & Branch     67108864
+      branch aka             Branches    181362688
+      advlsm aka     AdvSimd ldstmult       262144
+     advlsmp aka   AdvSimd ldstmult++      4194304
+      advlss aka         AdvSimd ldst       524288
+     advlssp aka       AdvSimd ldst++     16777216
+       ldstx aka            ldst excl     67108864
+        prfm aka             Prefetch     16777216
+       ldlit aka       Load Reg (lit)    251658240
+     ldstnap aka    ldst noalloc pair     67108864
+       ldstp aka            ldst pair    469762048
+       ldstr aka             ldst reg            0
+      atomic aka          Atomic ldst            0
+      ldstro aka   ldst reg (reg off)            0
+      ldstpa aka       ldst reg (pac)            0
+       ldsti aka       ldst reg (imm)    134217728
+        ldst aka       Loads & Stores    313786368
+        dprr aka        Data Proc Reg    402653184
+      fpsimd aka           Scalar FP     402653183
+      unclas aka         Unclassified    536870912
+```
+Steps to reproduce:
+1. Write a simple wrapper program; iterate and search through all 2**32 insns, dump the array
+2.
+3.
diff --git a/results/classifier/zero-shot/118/peripherals/865 b/results/classifier/zero-shot/118/peripherals/865
new file mode 100644
index 00000000..93eed51e
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/865
@@ -0,0 +1,75 @@
+peripherals: 0.946
+graphic: 0.915
+register: 0.914
+semantic: 0.901
+permissions: 0.893
+hypervisor: 0.890
+assembly: 0.886
+debug: 0.870
+architecture: 0.866
+performance: 0.865
+VMM: 0.862
+virtual: 0.857
+arm: 0.851
+device: 0.846
+TCG: 0.841
+ppc: 0.836
+i386: 0.823
+PID: 0.810
+vnc: 0.807
+user-level: 0.795
+risc-v: 0.768
+kernel: 0.689
+KVM: 0.679
+socket: 0.679
+mistranslation: 0.675
+boot: 0.669
+x86: 0.648
+network: 0.634
+files: 0.569
+
+virtio-vga gtk,gl=on Black Screen or GLXGears picture
+Description of problem:
+Blank screen for tab with name `virtio-vga` on GTK interface, however, if I run `glxgears` before running the machine, I see the following image: 
+
+![image](/uploads/08d426ab748826e4f291e2e5ed838288/image.png)
+Steps to reproduce:
+1.Run the invocation command provided above
+
+#
+Additional information:
+The host when the problem is occurring is a Dell Precision 5110 laptop that have Hybrid Graphics. I am running X11 with nvidia as the main driver, I am not using nouveau, I am using the nvidia drivers installed by the debian package, here the corresponding information for the nvida card:
+
+```
+nvidia-smi
+```
+```
+Thu Feb 10 23:32:21 2022       
++-----------------------------------------------------------------------------+
+| NVIDIA-SMI 460.91.03    Driver Version: 460.91.03    CUDA Version: 11.2     |
+|-------------------------------+----------------------+----------------------+
+| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
+| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
+|                               |                      |               MIG M. |
+|===============================+======================+======================|
+|   0  Quadro M1000M       On   | 00000000:01:00.0 Off |                  N/A |
+| N/A   44C    P8    N/A /  N/A |    846MiB /  2004MiB |      6%      Default |
+|                               |                      |                  N/A |
++-------------------------------+----------------------+----------------------+
+                                                                               
++-----------------------------------------------------------------------------+
+| Processes:                                                                  |
+|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
+|        ID   ID                                                   Usage      |
+|=============================================================================|
+|    0   N/A  N/A      6926      G   /usr/lib/xorg/Xorg                528MiB |
+|    0   N/A  N/A      7223      G   ...b/firefox-esr/firefox-esr      238MiB |
+|    0   N/A  N/A      7363      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    276992      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    282023      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    282630      G   ...b/firefox-esr/firefox-esr        0MiB |
+|    0   N/A  N/A    322305      G   qemu-system-x86_64                 70MiB |
++-----------------------------------------------------------------------------+
+```
+
+##
diff --git a/results/classifier/zero-shot/118/peripherals/881637 b/results/classifier/zero-shot/118/peripherals/881637
new file mode 100644
index 00000000..0df44f06
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/881637
@@ -0,0 +1,51 @@
+peripherals: 0.902
+architecture: 0.895
+device: 0.889
+graphic: 0.887
+assembly: 0.884
+files: 0.846
+socket: 0.843
+network: 0.841
+performance: 0.810
+hypervisor: 0.799
+semantic: 0.799
+user-level: 0.792
+permissions: 0.783
+virtual: 0.758
+kernel: 0.743
+register: 0.734
+debug: 0.731
+PID: 0.719
+i386: 0.702
+ppc: 0.695
+risc-v: 0.687
+arm: 0.642
+mistranslation: 0.611
+VMM: 0.580
+vnc: 0.547
+x86: 0.539
+boot: 0.505
+TCG: 0.455
+KVM: 0.306
+
+QEMU fails to build on OpenBSD/hppa
+
+Trying to build previous QEMU releases as well as git code fails on OpenBSD/hppa...
+
+cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa  -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE  -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include    -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g  -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c
+/tmp//ccvNbj1U.s: Assembler messages:
+/tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776).
+/tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096).
+/tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136).
+/tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612).
+/tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260).
+/tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784).
+/tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636).
+/tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280).
+
+The compiler used with the previous comment was GCC 4.2.1. I also tried building with GCC 4.6.3 and it experiences the same error during the build.
+
+Do you still have this problem with the latest version of QEMU and a more recent version of GCC?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/897750 b/results/classifier/zero-shot/118/peripherals/897750
new file mode 100644
index 00000000..2316bbc8
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/897750
@@ -0,0 +1,405 @@
+peripherals: 0.958
+TCG: 0.926
+hypervisor: 0.912
+user-level: 0.901
+ppc: 0.896
+VMM: 0.895
+debug: 0.893
+mistranslation: 0.875
+graphic: 0.867
+x86: 0.866
+semantic: 0.862
+device: 0.855
+virtual: 0.838
+assembly: 0.832
+register: 0.832
+vnc: 0.827
+PID: 0.818
+permissions: 0.814
+architecture: 0.799
+performance: 0.796
+KVM: 0.790
+risc-v: 0.789
+arm: 0.788
+socket: 0.743
+network: 0.696
+kernel: 0.684
+i386: 0.648
+boot: 0.613
+files: 0.531
+
+libvirt/kvm problem with disk attach/detach/reattach on running virt
+
+Release:         Ubuntu 11.10 (Oneiric)
+libvirt-bin:      0.9.2-4ubuntu15.1
+qemu-kvm:   0.14.1+noroms-0ubuntu6
+
+Summary:    With a running KVM virt,   performing an 'attach-disk',  then a 'detach-disk', then another 'attach-disk' 
+in an attempt to reattach the volume at the same point on the virt, fails, with the qemu reporting back to
+libvirt a 'Duplicate ID' error.
+
+Expected behavior:   The 2nd invocation of 'attach-disk' should have succeeded
+Actual behavior:         Duplicate ID error reported
+
+
+I believe this is most likely a qemu-kvm issue, as the DOM  kvm spits back at libvirt after the 'detach-disk'
+does not show the just-detached disk.   There is some kind of registry/lookup for devices in qemu-kvm
+and for whatever reason, the entry for the disk does not get removed when it is detached from the
+virt.   Specifically, the error gets reported at the 2nd attach-disk attempt from:
+  
+  qemu-option.c:qemu_opts_create:697
+
+684 QemuOpts *qemu_opts_create(QemuOptsList *list, const char *id, int fail_if_exists)                                                  
+685 {                                                                                                                                   
+686     QemuOpts *opts = NULL;                                                                                                          
+687                                                                                                                                     
+688     if (id) {                                                                                                                       
+689         if (!id_wellformed(id)) {                                                                                                   
+690             qerror_report(QERR_INVALID_PARAMETER_VALUE, "id", "an identifier");                                                     
+691             error_printf_unless_qmp("Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.\n");            
+692             return NULL;                                                                                                            
+693         }                                                                                                                           
+694         opts = qemu_opts_find(list, id);                                                                                            
+695         if (opts != NULL) {                                                                                                         
+696             if (fail_if_exists) {                                                                                                   
+697                 qerror_report(QERR_DUPLICATE_ID, id, list->name);           <<<< ====== HERE ===========                                                          
+698                 return NULL;                                                                                                        
+699             } else {                                                                                                                
+700                 return opts;                                                                                                        
+701             }                                                                                                                       
+702         }                                                                                                                           
+703     }                                                                                                                               
+704     opts = qemu_mallocz(sizeof(*opts));                                                                                             
+705     if (id) {                                                                                                                       
+706         opts->id = qemu_strdup(id);                                                                                                 
+707     }                                                                                                                               
+708     opts->list = list;                                                                                                              
+709     loc_save(&opts->loc);                                                                                                           
+710     QTAILQ_INIT(&opts->head);                                                                                                       
+711     QTAILQ_INSERT_TAIL(&list->head, opts, next);                                                                                    
+712     return opts;                                                                                                                    
+713 }                                                                                                                                   
+
+========================================
+Output of my  attach/detach/attach
+========================================
+virsh # attach-disk base1 /var/lib/libvirt/images/extrastorage.img vdb
+Disk attached successfully
+
+virsh # dumpxml base1
+<domain type='kvm' id='2'>
+  <name>base1</name>
+  <uuid>9ebebe7f-7dfa-4735-a80c-c19ebe4e1459</uuid>
+  <memory>1048576</memory>
+  <currentMemory>1048576</currentMemory>
+  <vcpu>2</vcpu>
+  <os>
+    <type arch='x86_64' machine='pc-0.14'>hvm</type>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <pae/>
+  </features>
+  <cpu match='exact'>
+    <model>Opteron_G3</model>
+    <vendor>AMD</vendor>
+    <feature policy='require' name='skinit'/>
+    <feature policy='require' name='vme'/>
+    <feature policy='require' name='mmxext'/>
+    <feature policy='require' name='fxsr_opt'/>
+    <feature policy='require' name='cr8legacy'/>
+    <feature policy='require' name='ht'/>
+    <feature policy='require' name='3dnowprefetch'/>
+    <feature policy='require' name='3dnowext'/>
+    <feature policy='require' name='wdt'/>
+    <feature policy='require' name='extapic'/>
+    <feature policy='require' name='pdpe1gb'/>
+    <feature policy='require' name='osvw'/>
+    <feature policy='require' name='cmp_legacy'/>
+    <feature policy='require' name='3dnow'/>
+  </cpu>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/bin/kvm</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='raw'/>
+      <source file='/dev/rbd1'/>
+      <target dev='vda' bus='virtio'/>
+      <alias name='virtio-disk0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </disk>
+    <disk type='block' device='disk'>
+      <driver name='qemu' type='raw'/>
+      <source dev='/var/lib/libvirt/images/extrastorage.img'/>
+      <target dev='vdb' bus='virtio'/>
+      <alias name='virtio-disk1'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </disk>
+    <controller type='ide' index='0'>
+      <alias name='ide0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='52:54:00:a2:c1:2d'/>
+      <source bridge='br0'/>
+      <target dev='vnet0'/>
+      <model type='virtio'/>
+      <alias name='net0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <source path='/dev/pts/1'/>
+      <target port='0'/>
+      <alias name='serial0'/>
+    </serial>
+    <console type='pty' tty='/dev/pts/1'>
+      <source path='/dev/pts/1'/>
+      <target type='serial' port='0'/>
+      <alias name='serial0'/>
+    </console>
+    <input type='mouse' bus='ps2'/>
+    <graphics type='vnc' port='5900' autoport='yes'/>
+    <sound model='ich6'>
+      <alias name='sound0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </sound>
+    <video>
+      <model type='cirrus' vram='9216' heads='1'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </memballoon>
+  </devices>
+  <seclabel type='dynamic' model='apparmor'>
+    <label>libvirt-9ebebe7f-7dfa-4735-a80c-c19ebe4e1459</label>
+    <imagelabel>libvirt-9ebebe7f-7dfa-4735-a80c-c19ebe4e1459</imagelabel>
+  </seclabel>
+</domain>
+
+virsh # detach-disk base1 vdb
+Disk detached successfully
+
+virsh # dumpxml base1
+<domain type='kvm' id='2'>
+  <name>base1</name>
+  <uuid>9ebebe7f-7dfa-4735-a80c-c19ebe4e1459</uuid>
+  <memory>1048576</memory>
+  <currentMemory>1048576</currentMemory>
+  <vcpu>2</vcpu>
+  <os>
+    <type arch='x86_64' machine='pc-0.14'>hvm</type>
+    <boot dev='hd'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <pae/>
+  </features>
+  <cpu match='exact'>
+    <model>Opteron_G3</model>
+    <vendor>AMD</vendor>
+    <feature policy='require' name='skinit'/>
+    <feature policy='require' name='vme'/>
+    <feature policy='require' name='mmxext'/>
+    <feature policy='require' name='fxsr_opt'/>
+    <feature policy='require' name='cr8legacy'/>
+    <feature policy='require' name='ht'/>
+    <feature policy='require' name='3dnowprefetch'/>
+    <feature policy='require' name='3dnowext'/>
+    <feature policy='require' name='wdt'/>
+    <feature policy='require' name='extapic'/>
+    <feature policy='require' name='pdpe1gb'/>
+    <feature policy='require' name='osvw'/>
+    <feature policy='require' name='cmp_legacy'/>
+    <feature policy='require' name='3dnow'/>
+  </cpu>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/bin/kvm</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='raw'/>
+      <source file='/dev/rbd1'/>
+      <target dev='vda' bus='virtio'/>
+      <alias name='virtio-disk0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </disk>
+    <controller type='ide' index='0'>
+      <alias name='ide0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='52:54:00:a2:c1:2d'/>
+      <source bridge='br0'/>
+      <target dev='vnet0'/>
+      <model type='virtio'/>
+      <alias name='net0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <source path='/dev/pts/1'/>
+      <target port='0'/>
+      <alias name='serial0'/>
+    </serial>
+    <console type='pty' tty='/dev/pts/1'>
+      <source path='/dev/pts/1'/>
+      <target type='serial' port='0'/>
+      <alias name='serial0'/>
+    </console>
+    <input type='mouse' bus='ps2'/>
+    <graphics type='vnc' port='5900' autoport='yes'/>
+    <sound model='ich6'>
+      <alias name='sound0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </sound>
+    <video>
+      <model type='cirrus' vram='9216' heads='1'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </memballoon>
+  </devices>
+  <seclabel type='dynamic' model='apparmor'>
+    <label>libvirt-9ebebe7f-7dfa-4735-a80c-c19ebe4e1459</label>
+    <imagelabel>libvirt-9ebebe7f-7dfa-4735-a80c-c19ebe4e1459</imagelabel>
+  </seclabel>
+</domain>
+
+virsh # attach-disk base1 /var/lib/libvirt/images/extrastorage.img vdb
+error: Failed to attach disk
+error: operation failed: adding virtio-blk-pci,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 device failed: Duplicate ID 'virtio-disk1' for device
+======================================================
+
+reproduced in precise as well.
+
+Actually this may be a libvirt bug.  Using 'qemu -monitor stdio -vnc :1 -hda qatest.img -snapshot', i can do:
+
+(qemu) drive_add 1 if=none,id=x,file=../x.img
+OK
+(qemu) drive_del x
+(qemu) drive_add 1 if=none,id=x,file=../x.img
+OK
+
+
+But, I think that the 'Duplicate ID' messages is generated from within qemu-kvm,  so perhaps an interaction between libvirt/qemu.
+
+(qemu) device_add driver=ne2k_pci,id=x
+(qemu) device_del x
+(qemu) device_add driver=ne2k_pci,id=x
+Duplicate ID 'x' for device
+
+It appears that drive_add/drive_del works fine, but device_del does not
+fully delete its members.
+
+This happens with today's git HEAD of qemu as well, in other words it affects upstream.
+
+
+I've been looking at libvirt and qemu for other work, I'm doing, and I've criceld back to take another look at this.
+
+Since I first looked at this, my testbed has updated to use the "oneiric-proposed"  
+   qemu-kvm package '0.14.1+noroms-0ubuntu6.1'
+while retaining the libvirt-bin package
+   0.9.2-4ubuntu15.1
+
+I tried to duplicate the problem again, but this time my  Linux virt had 'acpiphp.ko'
+(the PCI hotplug module) loaded, and I was *unable* to reproduce the 'Duplicate ID'
+error.  Instead, continued attach/detach cycles resulted in success every time after
+.gt. 30 iterations.
+
+==
+**As a side-note  and possibly to be addressed as a separate bug, the drive does not
+actually get attached as the specified device each time inside the virt.   So even though
+the 'attach-disk --target' specifies, say, vdb,  the virt kernel increments the devname
+inside itself, so that we get  vdc,  vdd, vde....  The attaches subsequent to the detatch
+of vdz results in vdaa,, vdab, vdac and so on.
+==
+
+Now here's the kicker.  If you do an 'rmmod' on the PCI hotplug module within the
+virt and try the attach/detach/attach, the 'Duplicate ID' problem re-occurs.   This
+implies to me that there is some sort of effective interaction between qemu-kvm
+and the virt that affects this.   That is, when the virt actually gets and handles a
+device eject, then qemu-kvm behaves differently than when  the virt does not
+get/handle it.
+--
+Dec 14 09:54:16 base1 kernel: [ 2226.835417] acpiphp_glue: handle_hotplug_event_func: Device eject notify on \_SB_.PCI0.S27_
+Dec 14 09:54:16 base1 kernel: [ 2226.877208] virtio-pci 0000:00:1b.0: PCI INT A disabled
+--
+
+So, this gives us a better characterization of the bug, and I will look into it some more with this
+in mind.
+
+Some incremental findings:
+
+In 'qemu-kvm'  the DeviceState for the peer device of the BlockDeviceState that gets created when a disk attached by 'virsh attach-disk' references the  'QemuOpts' options structure that lists the options and the device ID string (ex: as 'virtio-disk4') that will (on a re-attach for the same disk when the hotplug module is not loaded in the virt) be found by 'qemu_find_opts()' under the call to 'drive_add'.
+
+When the PCI hotplug module *is* loaded in the virt,  the DriveState structure and the associatsd QemuOpts get released from within a separate thread by a call to 'qdev_free()' asynchronously from the main thread's invocation of 'do_device_del()'.     When the PCI hotplug modules is *not* loaded in the virt, there is never an invocation of 'qdev_free' for the device , so the options structure hangs around to be located in the attempt to re-attach a disk for the same disk, and we get the Duplicate ID error.      In the even of the hotplug module being loaded in the virt, the trace of the thread which invokes 'qdev_free' looks something like:
+==
+#1  0x00007fbb4b3403d9 in qdev_free (dev=0x7fbb4cc8d820) at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/hw/qdev.c:382
+#2  0x00007fbb4b4aabd7 in pciej_write (opaque=0x7fbb4c95dc90, addr=44552, val=33554432)
+    at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/hw/acpi_piix4.c:615
+#3  0x00007fbb4b309839 in ioport_write (index=2, address=44552, data=33554432) at ioport.c:81
+#4  0x00007fbb4b30a2c7 in cpu_outl (addr=44552, val=33554432) at ioport.c:278
+#5  0x00007fbb4b2a7b82 in kvm_handle_io (port=44552, data=0x7fbb4b1fa000, direction=1, size=4, count=1)
+    at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/kvm-all.c:824
+#6  0x00007fbb4b2aa353 in kvm_run (env=0x7fbb4c734860) at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/qemu-kvm.c:617
+#7  0x00007fbb4b2abab8 in kvm_cpu_exec (env=0x7fbb4c734860) at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/qemu-kvm.c:1233
+#8  0x00007fbb4b2ac2dd in kvm_main_loop_cpu (env=0x7fbb4c734860) at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/qemu-kvm.c:1419
+#9  0x00007fbb4b2ac476 in ap_main_loop (_env=0x7fbb4c734860) at /home/justinlw/src/qemu/qemu-kvm-0.14.1+noroms/qemu-kvm.c:1466
+#10 0x00007fbb4a9bbefc in start_thread (arg=0x7fbb4397f700) at pthread_create.c:304
+#11 0x00007fbb481c589d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
+#12 0x0000000000000000 in ?? ()
+==
+
+In a nutshell, the code is designed such that there is a resource leak if the virt does not play ball with PCI hotplugging in a case like this.   I have yet to do complete line of code: I will have to have a much better understanding of the Qemu PCI handling mechanisms first, I think.    Still I believe there are potentially useful findings in further nailing this bug (design feature?).
+
+I find that you should modprobe 'acpiphp' & 'pci_hotplug' modules in the VM(ubuntu only has 'acpiphp', but it doesn't matter), then this problem will be resolved.
+http://www.linux-kvm.org/page/Hotadd_pci_devices
+
+pci_hotplog actually is available, at least on precise.  But it is not loaded (acpiphp is).
+
+After I modprobe pci_hotplug, the problem goes away.  Thanks wangpan.
+
+Hi Stefan,
+
+I'm assigning this bug to you to get your input about which package I need to target it to.  It's invalid (I believe) for qemu-kvm.  We need server cloud guests to have pci_hotplog auto-loaded at boot (to avoid this bug).  Should I assign to package linux for that?
+
+For the cloud-images specifically, this problem was solved once before in bug 450463.  our cloud-images have the following in their /etc/modules:
+# /etc/modules: kernel modules to load at boot time.
+#
+# This file contains the names of kernel modules that should be loaded
+# at boot time, one per line. Lines beginning with "#" are ignored.
+# LP: #450463
+acpiphp
+
+It has been "good enough" since karmic to have that there, we can probably add pci_hotplug there also.
+
+
+I am quite confused. Looking at my Precise system, pci-hotplug is built-in, and the configs for Oneiric and Quantal are the same. Could you tell me the exact kernel version for which you see this as a module?
+
+@Stefan,
+
+I'm confused too.  I don't have the VM I saw that on available right now, but think it was a quantal image built from the net install cd.
+
+On a precise server image, pci_hotplug is indeed built in.  acpiphp is NOT being auto-loaded.   (<<<<  smoser <<<<<)
+
+Serge, Scott, somehow I think we all left here in a confused state and I do not think we still have the problem (at least not Trusty). From my last comment it seems I did not even find something that I could change for Precise. For now I would unassign myself and maybe this report should be closed if Justin has no objections.
+
+Is here still a problem left with upstream QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/peripherals/899 b/results/classifier/zero-shot/118/peripherals/899
new file mode 100644
index 00000000..fa3d6b0a
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/899
@@ -0,0 +1,44 @@
+peripherals: 0.987
+network: 0.983
+graphic: 0.982
+kernel: 0.975
+boot: 0.945
+device: 0.942
+virtual: 0.923
+performance: 0.906
+vnc: 0.891
+assembly: 0.873
+semantic: 0.862
+arm: 0.826
+user-level: 0.791
+hypervisor: 0.790
+permissions: 0.773
+architecture: 0.728
+register: 0.725
+files: 0.715
+risc-v: 0.662
+PID: 0.655
+socket: 0.654
+debug: 0.637
+ppc: 0.624
+VMM: 0.619
+mistranslation: 0.617
+i386: 0.358
+TCG: 0.295
+KVM: 0.223
+x86: 0.145
+
+HVF: Ubuntu Server fails to boot Linux 5.4.0-104
+Description of problem:
+On macOS with HVF, when Ubuntu Server updates the Linux kernel to 5.4.0-104, it no longer boots and gets stuck at `EFI stub: Exiting boot services and installing virtual address map...`. This is not the case with QEMU 6.0.0 (with @agraf's HVF patches applied).
+
+It seems like 5.4.0-104 is the culprit because 5.4.0-100 boots fine.
+Steps to reproduce:
+1. Download Ubuntu Server 20.04 ARM64 ISO: https://ubuntu.com/download/server/arm
+2. Run the above QEMU command (make sure networking is disabled so Ubuntu installer does not auto-upgrade the kernel)
+3. Install Ubuntu with the default settings and reboot
+4. It will not reboot (expected) so Ctrl+C and restart the command adding `-device virtio-net-pci,netdev=net0 -netdev user,id=net0` to the end to get networking
+5. Boot into Ubuntu and install 5.4.0-104 kernel: `sudo apt install linux-image-5.4.0-104-generic`
+6. Reboot and it will get stuck at `EFI stub: Exiting boot services and installing virtual address map...`
+Additional information:
+![image](/uploads/5151ce8ae43911f503411902d330470c/image.png)
diff --git a/results/classifier/zero-shot/118/peripherals/918 b/results/classifier/zero-shot/118/peripherals/918
new file mode 100644
index 00000000..f2a2411b
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/918
@@ -0,0 +1,31 @@
+peripherals: 0.889
+device: 0.792
+ppc: 0.723
+architecture: 0.648
+network: 0.540
+performance: 0.490
+semantic: 0.382
+register: 0.353
+boot: 0.317
+graphic: 0.309
+virtual: 0.284
+mistranslation: 0.274
+risc-v: 0.224
+arm: 0.219
+debug: 0.185
+user-level: 0.157
+assembly: 0.138
+PID: 0.131
+TCG: 0.131
+vnc: 0.123
+hypervisor: 0.104
+files: 0.099
+permissions: 0.096
+VMM: 0.091
+i386: 0.088
+socket: 0.070
+kernel: 0.025
+x86: 0.011
+KVM: 0.005
+
+TILE Cpu Host & Emulator support?
diff --git a/results/classifier/zero-shot/118/peripherals/93 b/results/classifier/zero-shot/118/peripherals/93
new file mode 100644
index 00000000..0837c46d
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/93
@@ -0,0 +1,31 @@
+peripherals: 0.936
+device: 0.855
+performance: 0.743
+semantic: 0.421
+arm: 0.386
+debug: 0.352
+graphic: 0.325
+virtual: 0.258
+permissions: 0.248
+boot: 0.246
+network: 0.244
+mistranslation: 0.223
+architecture: 0.221
+register: 0.197
+user-level: 0.186
+VMM: 0.170
+socket: 0.155
+assembly: 0.146
+ppc: 0.141
+vnc: 0.138
+PID: 0.110
+TCG: 0.105
+risc-v: 0.091
+files: 0.068
+hypervisor: 0.048
+i386: 0.040
+x86: 0.035
+kernel: 0.026
+KVM: 0.008
+
+qemu 1.4.2: usb keyboard not fully working
diff --git a/results/classifier/zero-shot/118/peripherals/937 b/results/classifier/zero-shot/118/peripherals/937
new file mode 100644
index 00000000..dbe8480c
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/937
@@ -0,0 +1,98 @@
+peripherals: 0.814
+ppc: 0.794
+permissions: 0.789
+risc-v: 0.789
+debug: 0.787
+virtual: 0.783
+user-level: 0.783
+register: 0.780
+device: 0.776
+KVM: 0.765
+performance: 0.763
+x86: 0.757
+graphic: 0.754
+architecture: 0.752
+hypervisor: 0.745
+TCG: 0.742
+arm: 0.740
+assembly: 0.728
+network: 0.721
+vnc: 0.710
+semantic: 0.709
+VMM: 0.706
+mistranslation: 0.694
+PID: 0.688
+files: 0.679
+boot: 0.664
+socket: 0.648
+kernel: 0.633
+i386: 0.591
+
+I/O errors occur when qcow2 files created via gluster fuse mount are accessed via libgfapi (gluster://)
+Description of problem:
+Environment: a Gluster volume 'v0' (Gluster versions tested were 9.2-1 and 10.1) is built on 3 nodes on top of 3 ZFS pools. It is mounted to check fuse mount functionality. Mount point is `/mnt/gl`.
+When an empty qcow2 is created via fuse mount (qemu-img create -f qcow2 /mnt/gl/123.qcow2 10G) and then this qcow2 is attached to qemu guest -- error appears:
+```
+qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}: Could not read L1 table: Input/output error
+```
+When the same file is attached to qemu guest via fuse mount there is no error. When the same file is created via GFAPI (gluster://) there is no error too.
+Steps to reproduce:
+1. Create file via fuse-mount: `qemu-img create -f qcow2 /mnt/gl/123.qcow2 10G`
+2. Attach this file via gluster:// to qemu guest and observe an error
+3. Attach this file via fuse mount, run a guest -- no error.
+4. Create file via gluster:// : `qemu-img create -f qcow2 gluster://v0/234.qcow2 10g`
+5. Attach this file (via GFAPI or via fuse mount) to qemu guest and run guest -- there is no error.
+Additional information:
+When an empty qcow2 file with virtual size 10G with default cluster size is created, its proper size is 196768 (0x300a0) bytes. If file is created via fuse mount, that is true and file size is 0x300a0 bytes.
+In the end of file L1 table resides, its offset is 0x30000 and size is 0xa0. When this qcow2 is attached via fuse mount it seems that i/o requests are conforming to file size and file is read without errors. 
+But when file with size 0x300a0 is attached via gluster://, qemu aligns i/o requests by 0x200 bytes boundary (see dump below, frame #12. NB: dump is taken from qemu-img create cmd so there are write requests). Thus, request goes beyond the file end and read error occurs.
+
+When file is created via gluster:// its size is 197120 (0x30200) bytes because write requests are aligned to 512 bytes too. And guest runs normally with it regardless of connection type.
+
+```
+Thread 1 "qemu-img" hit Breakpoint 1, 0x00007fffec014f10 in ec_gf_writev () from /usr/lib64/glusterfs/11dev/xlator/cluster/disperse.so
+(gdb) bt
+#0  0x00007fffec014f10 in ec_gf_writev () from /usr/lib64/glusterfs/11dev/xlator/cluster/disperse.so
+#1  0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0
+#2  0x00007ffff4024ab8 in gf_utime_writev (frame=0x555556126aa8, this=0x7fffe40113d8, fd=0x555556126b88, vector=0x555556130868, count=1, off=196608, flags=0, iobref=0x555556130608, xdata=0x0) at utime-autogen-fops.c:81
+#3  0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0
+#4  0x00007ffff4013c39 in ob_writev (frame=frame@entry=0x555556126aa8, this=0x7fffe4012408, fd=fd@entry=0x555556126b88, iov=iov@entry=0x555556130868, count=count@entry=1, offset=offset@entry=196608, flags=0,
+    iobref=0x555556130608, xdata=0x0) at open-behind.c:584
+#5  0x00007fffdff37774 in mdc_writev (frame=frame@entry=0x5555561522d8, this=0x7fffe40139e8, fd=fd@entry=0x555556126b88, vector=vector@entry=0x555556130868, count=count@entry=1, offset=offset@entry=196608, flags=0,
+    iobref=0x555556130608, xdata=0x0) at md-cache.c:2151
+#6  0x00007fffdff143fb in io_stats_writev (frame=0x55555611dc08, this=0x7fffe4015468, fd=0x555556126b88, vector=0x555556130868, count=1, offset=196608, flags=0, iobref=0x555556130608, xdata=0x0) at io-stats.c:2952
+#7  0x00007ffff68eeea6 in default_writev () from /lib64/libglusterfs.so.0
+#8  0x00007fffdfee88ca in meta_writev (frame=0x55555611dc08, this=0x7fffe40173d8, fd=0x555556126b88, iov=0x555556130868, count=1, offset=196608, flags=0, iobref=0x555556130608, xdata=0x0) at meta.c:131
+#9  0x00007ffff6942f22 in glfs_pwritev_async_common () from /lib64/libgfapi.so.0
+#10 0x00007ffff69462f6 in glfs_pwritev_async () from /lib64/libgfapi.so.0
+#11 0x00007ffff7fc5839 in qemu_gluster_co_writev () from /usr/lib64/qemu/block-gluster.so
+#12 0x0000555555623b7e in bdrv_driver_pwritev (bs=bs@entry=0x55555611eda0, offset=offset@entry=196608, bytes=bytes@entry=512, qiov=qiov@entry=0x7ffff5e9cb40, qiov_offset=qiov_offset@entry=0, flags=flags@entry=0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1243
+#13 0x00005555556244d2 in bdrv_aligned_pwritev (child=child@entry=0x55555611e3a0, req=req@entry=0x7ffff5e9ca80, offset=196608, bytes=512, align=align@entry=512, qiov=0x7ffff5e9cb40, qiov_offset=0, flags=0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:2020
+#14 0x0000555555625433 in bdrv_co_pwritev_part (child=0x55555611e3a0, offset=<optimized out>, bytes=<optimized out>, qiov=<optimized out>, qiov_offset=<optimized out>, flags=0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:2188
+#15 0x00005555556267a0 in bdrv_run_co (opaque=0x7ffff5e9cbb0, entry=0x5555556260a0 <bdrv_rw_co_entry>, bs=0x55555611eda0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:915
+#16 bdrv_prwv_co (flags=0, is_write=true, qiov=0x7ffff5e9cbd0, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:966
+#17 bdrv_pwritev (qiov=0x7ffff5e9cbd0, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1048
+#18 bdrv_pwrite (bytes=160, buf=0x555556116000, offset=196608, child=0x55555611e3a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1070
+#19 bdrv_pwrite_sync (child=0x55555611e3a0, offset=offset@entry=196608, buf=buf@entry=0x555556116000, count=count@entry=160) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:1084
+#20 0x00005555555f60de in qcow2_grow_l1_table (bs=bs@entry=0x55555610d0a0, min_size=min_size@entry=20, exact_size=exact_size@entry=true) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2-cluster.c:161
+#21 0x00005555555ec252 in qcow2_co_truncate (bs=0x55555610d0a0, offset=<optimized out>, exact=<optimized out>, prealloc=PREALLOC_MODE_OFF, flags=0, errp=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:4172
+#22 0x000055555562758d in bdrv_co_truncate (child=0x55555617b290, offset=10737418240, exact=<optimized out>, prealloc=PREALLOC_MODE_OFF, flags=0, errp=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3394
+#23 0x0000555555627a01 in bdrv_truncate_co_entry (opaque=0x7ffff5e9ceb0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3437
+#24 bdrv_run_co (opaque=0x7ffff5e9ceb0, entry=0x555555627980 <bdrv_truncate_co_entry>, bs=0x55555610d0a0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:915
+#25 bdrv_truncate (child=<optimized out>, offset=<optimized out>, exact=<optimized out>, prealloc=<optimized out>, flags=flags@entry=0, errp=errp@entry=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/io.c:3453
+#26 0x0000555555611d32 in blk_truncate (blk=blk@entry=0x55555611e420, offset=<optimized out>, exact=exact@entry=false, prealloc=<optimized out>, flags=flags@entry=0, errp=errp@entry=0x7ffff5e9cfa0)
+    at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/block-backend.c:2184
+#27 0x00005555555e9a0f in qcow2_co_create (create_options=0x55555612c000, errp=errp@entry=0x7ffff5e9cfa0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:3614
+#28 0x00005555555ea0ec in qcow2_co_create_opts (drv=<optimized out>, filename=<optimized out>, opts=0x5555557a3f90, errp=0x7ffff5e9cfa0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block/qcow2.c:3795
+#29 0x00005555555bd631 in bdrv_create_co_entry (opaque=0x7fffffffdff0) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/block.c:487
+#30 0x00005555556a7d8b in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at /usr/src/debug/qemu-5.1.0-9.fc33.x86_64/util/coroutine-ucontext.c:173
+#31 0x00007ffff76a01c0 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 from /lib64/libc.so.6
+#32 0x00007fffffffd820 in ?? ()
+#33 0x0000000000000000 in ?? ()
+```
diff --git a/results/classifier/zero-shot/118/peripherals/938552 b/results/classifier/zero-shot/118/peripherals/938552
new file mode 100644
index 00000000..05c8bf32
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/938552
@@ -0,0 +1,58 @@
+peripherals: 0.896
+performance: 0.878
+graphic: 0.860
+device: 0.835
+semantic: 0.707
+files: 0.706
+mistranslation: 0.669
+architecture: 0.651
+user-level: 0.633
+network: 0.583
+ppc: 0.576
+PID: 0.560
+boot: 0.546
+permissions: 0.534
+kernel: 0.529
+register: 0.464
+hypervisor: 0.454
+socket: 0.448
+KVM: 0.411
+VMM: 0.409
+x86: 0.408
+arm: 0.388
+i386: 0.385
+vnc: 0.375
+virtual: 0.355
+debug: 0.353
+TCG: 0.319
+risc-v: 0.311
+assembly: 0.246
+
+ENH: Inherit ptys, useful output from -serial pty
+
+When controlling a qemu instance from another program, it'd be very useful to be able to have qemu inherit pseudo-tty file descriptors so they could just be specified on the command line.
+
+It's possible to allocate a pty pair in the master program before forking and exec'ing qemu and have qemu use that pty, but it's a bit painful. The master program must call ptsname(...) on the fd of the slave side and insert the path to the pty device node into qemu's command line. This doesn't work well in many scripting languages which lack a ptsname() call; a Linux-specific hack like readlink() of /proc/self/fd/[slave-fd] is necessary.
+
+If qemu accepted file descriptors for serial I/O this would all be a lot more flexible, and it wouldn't be limited to ptys either. Just accept a new format for "-serial" like "-serial fd:7" and have the parent program not set that FD to close-on-exec.
+
+None of this would be as necessary if qemu's "-serial pty" option was fully functional. Unfortunately, it doesn't provide any information to associate the created PTY(s) with their qemu devices, so it's hard to know which serial port is which, which the monitor device is, etc. See, eg:
+
+$ qemu -serial pty -serial pty -monitor pty
+char device redirected to /dev/pts/6
+char device redirected to /dev/pts/7
+char device redirected to /dev/pts/8
+
+... which is which? Are they allocated in the order they're specified on the command line? Nope, because /dev/pts/6 is the monitor in this case. With more than one device using "pty" a lot of guesswork is involved.
+
+If you're using "-monitor stdio" you can issue an "info chardev" and parse that to find out what everything else is connected to, but this shouldn't really be necessary. Ideally the device names would be printed when a port is redirected to a pty, eg:
+
+$ qemu -serial pty -serial pty -monitor pty
+char device compat_monitor0 redirected to /dev/pts/6
+char device serial0 redirected to /dev/pts/7
+char device serial1 redirected to /dev/pts/8
+
+Looks like a fix for this has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=586502189edf9fd0f89a83d
+... so I think it should be OK to close this ticket now.
+
diff --git a/results/classifier/zero-shot/118/peripherals/98 b/results/classifier/zero-shot/118/peripherals/98
new file mode 100644
index 00000000..bf6f7905
--- /dev/null
+++ b/results/classifier/zero-shot/118/peripherals/98
@@ -0,0 +1,31 @@
+peripherals: 0.962
+device: 0.934
+graphic: 0.931
+performance: 0.450
+mistranslation: 0.356
+user-level: 0.348
+debug: 0.315
+ppc: 0.311
+semantic: 0.233
+risc-v: 0.129
+vnc: 0.113
+boot: 0.088
+assembly: 0.073
+TCG: 0.071
+PID: 0.059
+arm: 0.057
+register: 0.043
+VMM: 0.038
+permissions: 0.021
+architecture: 0.021
+socket: 0.020
+virtual: 0.018
+i386: 0.015
+network: 0.010
+files: 0.010
+kernel: 0.005
+x86: 0.005
+KVM: 0.004
+hypervisor: 0.003
+
+Curses Keyboard Broken On OS X
-- 
cgit 1.4.1