9 files changed, 803 insertions, 0 deletions
diff --git a/results/classifier/118/semantic-x86/1370 b/results/classifier/118/semantic-x86/1370
new file mode 100644
index 000000000..704326756
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1370
@@ -0,0 +1,73 @@
+x86: 0.998
+semantic: 0.986
+architecture: 0.935
+i386: 0.888
+graphic: 0.878
+assembly: 0.842
+device: 0.806
+socket: 0.681
+ppc: 0.679
+vnc: 0.658
+kernel: 0.638
+network: 0.606
+permissions: 0.580
+boot: 0.546
+arm: 0.541
+performance: 0.523
+mistranslation: 0.502
+debug: 0.478
+risc-v: 0.458
+files: 0.411
+TCG: 0.360
+register: 0.322
+peripherals: 0.303
+PID: 0.269
+VMM: 0.256
+virtual: 0.254
+KVM: 0.210
+hypervisor: 0.142
+user-level: 0.088
+--------------------
+x86: 1.000
+semantic: 0.987
+i386: 0.985
+assembly: 0.961
+debug: 0.185
+register: 0.174
+kernel: 0.052
+files: 0.042
+TCG: 0.041
+performance: 0.037
+virtual: 0.017
+architecture: 0.017
+user-level: 0.016
+PID: 0.010
+peripherals: 0.009
+VMM: 0.008
+device: 0.007
+hypervisor: 0.006
+boot: 0.006
+permissions: 0.005
+risc-v: 0.005
+network: 0.004
+KVM: 0.004
+graphic: 0.003
+socket: 0.002
+vnc: 0.001
+mistranslation: 0.001
+ppc: 0.000
+arm: 0.000
+
+x86 BLSI and BLSR semantic bug
+Description of problem:
+The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("blsi rax, rbx");
+}
+```
+2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too.
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/118/semantic-x86/1371 b/results/classifier/118/semantic-x86/1371
new file mode 100644
index 000000000..a433fc66a
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1371
@@ -0,0 +1,79 @@
+x86: 0.998
+semantic: 0.995
+assembly: 0.852
+graphic: 0.824
+i386: 0.808
+architecture: 0.799
+device: 0.665
+ppc: 0.601
+mistranslation: 0.491
+boot: 0.468
+vnc: 0.465
+socket: 0.452
+kernel: 0.422
+arm: 0.353
+register: 0.348
+permissions: 0.325
+network: 0.307
+debug: 0.306
+risc-v: 0.275
+files: 0.203
+performance: 0.197
+peripherals: 0.112
+PID: 0.103
+virtual: 0.083
+VMM: 0.082
+TCG: 0.073
+KVM: 0.064
+hypervisor: 0.041
+user-level: 0.019
+--------------------
+x86: 1.000
+semantic: 0.988
+i386: 0.987
+assembly: 0.957
+debug: 0.352
+register: 0.270
+kernel: 0.092
+files: 0.049
+performance: 0.045
+TCG: 0.030
+user-level: 0.027
+virtual: 0.024
+architecture: 0.015
+peripherals: 0.013
+device: 0.013
+VMM: 0.011
+PID: 0.011
+hypervisor: 0.010
+boot: 0.006
+network: 0.006
+KVM: 0.005
+socket: 0.005
+permissions: 0.005
+graphic: 0.003
+risc-v: 0.002
+vnc: 0.001
+mistranslation: 0.001
+ppc: 0.000
+arm: 0.000
+
+x86 BLSMSK semantic bug
+Description of problem:
+The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x65b2e276ad27c67");
+    asm("mov rbx, 0x62f34955226b2b5d");
+    asm("blsmsk eax, ebx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - CF = 0
+    - QEMU
+        - CF = 1
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/118/semantic-x86/1372 b/results/classifier/118/semantic-x86/1372
new file mode 100644
index 000000000..96c8dec2f
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1372
@@ -0,0 +1,80 @@
+x86: 0.998
+semantic: 0.995
+architecture: 0.914
+graphic: 0.860
+register: 0.829
+device: 0.736
+assembly: 0.728
+mistranslation: 0.574
+i386: 0.505
+vnc: 0.420
+boot: 0.411
+risc-v: 0.390
+ppc: 0.382
+debug: 0.352
+permissions: 0.340
+kernel: 0.295
+socket: 0.263
+arm: 0.205
+network: 0.171
+PID: 0.153
+performance: 0.140
+files: 0.125
+peripherals: 0.120
+VMM: 0.095
+KVM: 0.083
+TCG: 0.075
+virtual: 0.058
+hypervisor: 0.028
+user-level: 0.018
+--------------------
+x86: 1.000
+i386: 0.987
+semantic: 0.982
+assembly: 0.973
+debug: 0.546
+register: 0.253
+user-level: 0.131
+kernel: 0.057
+virtual: 0.052
+files: 0.045
+performance: 0.027
+TCG: 0.022
+hypervisor: 0.021
+architecture: 0.014
+PID: 0.014
+network: 0.013
+peripherals: 0.010
+device: 0.009
+VMM: 0.004
+risc-v: 0.004
+permissions: 0.004
+socket: 0.003
+boot: 0.003
+graphic: 0.002
+KVM: 0.002
+ppc: 0.002
+vnc: 0.001
+mistranslation: 0.001
+arm: 0.000
+
+x86 BEXTR semantic bug
+Description of problem:
+The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x17b3693f77fb6e9");
+    asm("mov rbx, 0x8f635a775ad3b9b4");
+    asm("mov rcx, 0xb717b75da9983018");
+    asm("bextr eax, ebx, ecx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - RAX = 0x5a
+    - QEMU
+        - RAX = 0x635a775a
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/118/semantic-x86/1373 b/results/classifier/118/semantic-x86/1373
new file mode 100644
index 000000000..2b5226352
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1373
@@ -0,0 +1,80 @@
+x86: 0.998
+semantic: 0.996
+assembly: 0.951
+architecture: 0.941
+graphic: 0.898
+i386: 0.835
+device: 0.784
+vnc: 0.746
+mistranslation: 0.642
+kernel: 0.593
+ppc: 0.573
+boot: 0.505
+socket: 0.502
+debug: 0.488
+permissions: 0.472
+arm: 0.465
+register: 0.422
+performance: 0.412
+network: 0.373
+risc-v: 0.317
+files: 0.298
+peripherals: 0.217
+PID: 0.169
+virtual: 0.143
+VMM: 0.139
+KVM: 0.113
+TCG: 0.102
+hypervisor: 0.066
+user-level: 0.040
+--------------------
+x86: 1.000
+semantic: 0.986
+i386: 0.984
+assembly: 0.966
+debug: 0.271
+register: 0.134
+files: 0.041
+TCG: 0.033
+kernel: 0.028
+performance: 0.023
+user-level: 0.016
+architecture: 0.015
+virtual: 0.011
+PID: 0.009
+device: 0.007
+peripherals: 0.006
+hypervisor: 0.005
+boot: 0.004
+VMM: 0.004
+network: 0.003
+socket: 0.003
+permissions: 0.003
+graphic: 0.003
+KVM: 0.002
+risc-v: 0.001
+vnc: 0.001
+ppc: 0.001
+mistranslation: 0.000
+arm: 0.000
+
+x86 ADOX and ADCX semantic bug
+Description of problem:
+The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("push 512; popfq;");
+    asm("mov rax, 0xffffffff84fdbf24");
+    asm("mov rbx, 0xb197d26043bec15d");
+    asm("adox eax, ebx");
+}
+```
+2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
+    - CPU
+        - OF = 0
+    - QEMU
+        - OF = 1
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/118/semantic-x86/1374 b/results/classifier/118/semantic-x86/1374
new file mode 100644
index 000000000..a4f364474
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1374
@@ -0,0 +1,82 @@
+x86: 0.997
+semantic: 0.993
+graphic: 0.807
+architecture: 0.761
+register: 0.732
+device: 0.700
+assembly: 0.661
+ppc: 0.428
+arm: 0.388
+boot: 0.382
+vnc: 0.341
+debug: 0.324
+socket: 0.314
+kernel: 0.307
+network: 0.272
+mistranslation: 0.272
+permissions: 0.246
+risc-v: 0.238
+peripherals: 0.199
+i386: 0.198
+performance: 0.192
+PID: 0.155
+files: 0.078
+virtual: 0.061
+VMM: 0.045
+KVM: 0.044
+TCG: 0.038
+user-level: 0.022
+hypervisor: 0.019
+--------------------
+x86: 1.000
+i386: 0.993
+semantic: 0.988
+assembly: 0.970
+debug: 0.228
+register: 0.206
+kernel: 0.077
+files: 0.043
+performance: 0.042
+TCG: 0.033
+user-level: 0.031
+virtual: 0.025
+architecture: 0.018
+hypervisor: 0.013
+peripherals: 0.012
+device: 0.012
+PID: 0.011
+VMM: 0.008
+network: 0.007
+boot: 0.006
+risc-v: 0.005
+socket: 0.005
+permissions: 0.005
+KVM: 0.005
+graphic: 0.003
+vnc: 0.001
+ppc: 0.001
+mistranslation: 0.001
+arm: 0.000
+
+x86 BZHI semantic bug
+Description of problem:
+The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0xb1aa9da2fe33fe3");
+    asm("mov rbx, 0x80000000ffffffff");
+    asm("mov rcx, 0xf3fce8829b99a5c6");
+    asm("bzhi rax, rbx, rcx");
+}
+```
+2. Execute and compare the result with the CPU.
+    - CPU
+        - RAX = 0x0x80000000ffffffff
+        - SF = 1
+    - QEMU
+        - RAX = 0xffffffff
+        - SF = 0
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/118/semantic-x86/1375 b/results/classifier/118/semantic-x86/1375
new file mode 100644
index 000000000..3e2f80950
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1375
@@ -0,0 +1,79 @@
+x86: 0.998
+semantic: 0.988
+architecture: 0.858
+graphic: 0.792
+device: 0.739
+assembly: 0.675
+i386: 0.626
+performance: 0.586
+ppc: 0.553
+vnc: 0.520
+permissions: 0.509
+debug: 0.468
+network: 0.458
+kernel: 0.414
+boot: 0.413
+socket: 0.407
+PID: 0.343
+risc-v: 0.341
+register: 0.317
+mistranslation: 0.269
+KVM: 0.247
+VMM: 0.247
+files: 0.241
+TCG: 0.235
+arm: 0.223
+peripherals: 0.200
+virtual: 0.184
+hypervisor: 0.166
+user-level: 0.104
+--------------------
+x86: 1.000
+semantic: 0.987
+assembly: 0.979
+i386: 0.927
+debug: 0.085
+user-level: 0.042
+files: 0.041
+register: 0.036
+risc-v: 0.020
+PID: 0.015
+architecture: 0.014
+performance: 0.014
+kernel: 0.014
+virtual: 0.014
+TCG: 0.012
+VMM: 0.011
+network: 0.008
+device: 0.005
+permissions: 0.004
+hypervisor: 0.004
+socket: 0.004
+peripherals: 0.003
+boot: 0.002
+vnc: 0.002
+graphic: 0.002
+KVM: 0.001
+ppc: 0.001
+mistranslation: 0.001
+arm: 0.000
+
+x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
+Description of problem:
+The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
+Steps to reproduce:
+1. Compile this code
+```
+void main() {
+    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
+    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
+    asm("addsubps xmm1, xmm2");
+}
+```
+2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
+    - CPU
+        - xmm1[3] = 0xffffffff
+    - QEMU
+        - xmm1[3] = 0x7fffffff
+Additional information:
+This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/118/semantic-x86/1754295 b/results/classifier/118/semantic-x86/1754295
new file mode 100644
index 000000000..ae5c96bee
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1754295
@@ -0,0 +1,77 @@
+x86: 0.968
+graphic: 0.839
+device: 0.836
+semantic: 0.807
+boot: 0.805
+architecture: 0.800
+vnc: 0.769
+performance: 0.749
+mistranslation: 0.740
+network: 0.684
+socket: 0.660
+files: 0.651
+PID: 0.632
+user-level: 0.630
+ppc: 0.599
+permissions: 0.564
+arm: 0.542
+peripherals: 0.524
+i386: 0.508
+kernel: 0.473
+debug: 0.469
+hypervisor: 0.462
+register: 0.431
+risc-v: 0.410
+VMM: 0.366
+KVM: 0.198
+TCG: 0.197
+virtual: 0.179
+assembly: 0.127
+--------------------
+x86: 0.971
+user-level: 0.959
+vnc: 0.929
+virtual: 0.770
+TCG: 0.188
+hypervisor: 0.155
+boot: 0.100
+debug: 0.098
+files: 0.038
+KVM: 0.032
+socket: 0.021
+network: 0.020
+kernel: 0.019
+register: 0.019
+device: 0.015
+VMM: 0.014
+PID: 0.009
+semantic: 0.006
+architecture: 0.005
+risc-v: 0.002
+assembly: 0.002
+ppc: 0.002
+performance: 0.002
+peripherals: 0.002
+i386: 0.001
+permissions: 0.001
+graphic: 0.001
+arm: 0.001
+mistranslation: 0.000
+
+Incorrect en-us keymap in QEMU 2.11
+
+I'm using the latest Arch Linux installation ISO as a live system and start QEMU with the following command:
+
+$ qemu-system-x86_64 -enable-kvm -boot d -cdrom ~/isos/archlinux-2018.03.01-x86_64.iso -m 512 -vnc :0 -k en-us
+
+Then I use Vinagre to connect to the guest system, boot the default bootloader option, and type the character '<' at the command prompt. The guest prints the character '>' instead of the '<' I typed.
+
+I believe this is caused by the updated en-us keymap in QEMU 2.11. [1]
+
+If I start QEMU with `-k en-gb` (or without the -k switch at all), I can type '<' and get the same character to appear on the guest's command line. The issue happens with the updated en-us keymap. It is also fixed if I replace /usr/share/qemu/keymaps/en-us with the old keymap file (before commit a7815faf).
+
+This problem was originally reported against Packer because we were seeing '>' characters in place of '<' when using it with the QEMU builder. [2]
+
+[1] https://github.com/qemu/qemu/commit/a7815faffb2bd594b92aa3542d7b799cc89c5414
+[2] https://github.com/hashicorp/packer/issues/5769
+
diff --git a/results/classifier/118/semantic-x86/1930 b/results/classifier/118/semantic-x86/1930
new file mode 100644
index 000000000..cdda54a62
--- /dev/null
+++ b/results/classifier/118/semantic-x86/1930
@@ -0,0 +1,106 @@
+x86: 0.937
+graphic: 0.880
+vnc: 0.852
+semantic: 0.835
+architecture: 0.825
+ppc: 0.793
+user-level: 0.791
+files: 0.790
+performance: 0.781
+PID: 0.761
+permissions: 0.760
+network: 0.743
+device: 0.740
+risc-v: 0.731
+socket: 0.720
+kernel: 0.696
+debug: 0.693
+TCG: 0.664
+VMM: 0.655
+boot: 0.637
+peripherals: 0.621
+hypervisor: 0.583
+virtual: 0.582
+register: 0.575
+arm: 0.567
+i386: 0.482
+assembly: 0.444
+mistranslation: 0.439
+KVM: 0.311
+--------------------
+x86: 0.968
+virtual: 0.376
+TCG: 0.186
+hypervisor: 0.114
+debug: 0.066
+PID: 0.060
+files: 0.059
+VMM: 0.048
+register: 0.038
+user-level: 0.028
+kernel: 0.026
+performance: 0.024
+architecture: 0.019
+device: 0.017
+risc-v: 0.015
+vnc: 0.011
+semantic: 0.011
+network: 0.011
+socket: 0.010
+peripherals: 0.006
+assembly: 0.005
+boot: 0.004
+ppc: 0.004
+graphic: 0.003
+arm: 0.002
+permissions: 0.002
+KVM: 0.001
+mistranslation: 0.001
+i386: 0.000
+
+qemu-aarch64 results in segmentation fault while running a test binary compiled for QNX
+Description of problem:
+We have cross compiled a simple hello world program for QNX SDP 7.1.0 on Ubuntu Focal x86_64. Running the binary using qemu-aarch64 results in segmentation fault error.
+
+```
+   $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world
+   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+   Segmentation fault (core dumped)
+```
+
+We also tried Ubuntu Jammy which has qemu-aarch64 v6.2.0 but got the same error.
+Can you tell us how we can emulate the binary using QEMU emulator that is built for QNX on x86_64 platform? Any help would be much appreciated.
+Steps to reproduce:
+1. Download QNX SDP from QNX software center https://www.qnx.com/download/group.html?programid=29178.
+2. Write a simple hello world program.
+
+```
+     #include <stdio.h>
+     
+     int main(void) {
+         return printf("Hello World!");
+     }
+```
+
+3. Source QNX SDP to set some environment variables.
+
+   `$ source ./qnx710/qnxsdp-env.sh`
+
+4. Compile using the QNX compiler.
+
+   `$ qcc -Vgcc_ntoaarch64le -o hello-world hello-world.c`
+
+5. Running the binary as it is results to:
+
+```
+   $ ./hello-world
+   aarch64-binfmt-P: Could not open '/usr/lib/ldqnx-64.so.2': No such file or directory
+```
+
+5. Running using QEMU emulator results to segmentation fault.
+
+```
+   $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world
+   qemu: uncaught target signal 11 (Segmentation fault) - core dumped  
+   Segmentation fault (core dumped)
+```
diff --git a/results/classifier/118/semantic-x86/568614 b/results/classifier/118/semantic-x86/568614
new file mode 100644
index 000000000..d47ebb6aa
--- /dev/null
+++ b/results/classifier/118/semantic-x86/568614
@@ -0,0 +1,147 @@
+semantic: 0.910
+peripherals: 0.906
+user-level: 0.897
+permissions: 0.892
+virtual: 0.892
+x86: 0.889
+kernel: 0.873
+register: 0.866
+hypervisor: 0.865
+mistranslation: 0.859
+architecture: 0.859
+arm: 0.858
+performance: 0.855
+socket: 0.853
+device: 0.847
+risc-v: 0.844
+assembly: 0.840
+KVM: 0.840
+PID: 0.833
+graphic: 0.827
+debug: 0.813
+VMM: 0.805
+TCG: 0.804
+ppc: 0.803
+vnc: 0.799
+files: 0.773
+network: 0.732
+boot: 0.728
+i386: 0.603
+--------------------
+x86: 0.974
+user-level: 0.198
+virtual: 0.077
+debug: 0.073
+TCG: 0.025
+files: 0.018
+semantic: 0.015
+PID: 0.014
+hypervisor: 0.010
+kernel: 0.010
+register: 0.009
+network: 0.009
+device: 0.006
+VMM: 0.006
+risc-v: 0.004
+graphic: 0.004
+assembly: 0.004
+boot: 0.004
+architecture: 0.003
+ppc: 0.003
+vnc: 0.003
+performance: 0.003
+socket: 0.003
+peripherals: 0.002
+mistranslation: 0.001
+permissions: 0.001
+i386: 0.001
+KVM: 0.001
+arm: 0.000
+
+x86_64 host curses interface: spacing/garbling
+
+Environment:
+Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3
+
+Steps to reproduce:
+1. Have a host system running 64-bit Linux.
+2. Start a qemu VM with the -curses flag.
+
+Expected results:
+Text displayed looks as it would on a real text-mode display, and VM is therefore usable.
+
+Actual results:
+Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible.
+
+The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine.  I don't know enough of the semantics of console_ch_t to know if this is the "correct" fix or if there should be, say, an extra cast somewhere instead.
+
+
+
+Just compiled qemu from git to check for bug, and it is still present.
+
+This patch should address the problem.  I've submitted it to qemu-devel.
+
+Perhaps you have found an endianness bug as well, but my issue is with word size (my host is a 64-bit Intel).  I manually applied the patch to a 0.12.3 build, and I am still seeing the problem with the curses console.
+
+It seems that the console_ch_t type is used in a number of different contexts.  The console.c and console.h files use console_ch_t fairly uniformly.  However, the `screen' array in curses.c is cast to both uint8_t* and chtype* (unsigned int* according to my curses library) and passed as console_ch_t* (unsigned long*) to vga_hw_text_update.  That's three different bit-sizes on my machine... is it possible that the problem lies here?
+
+Hi Devin,
+
+Can you test if this bug still exists with 0.14 (or better still, a git build)?
+
+Brad
+
+
+I just compiled from git and the problem persists.
+
+I will reiterate that the issue appears to be with the word size of the types used, not with endianness; see comment 4.  I have not dug any further into the QEMU code to see if I find a more "correct-looking" solution than the quick patch I have attached to this bug.
+
+any news on that bug?
+
+If I remember correctly, the type is unsigned long because it needs to match "chtype" as declared in curses.h.  On some implementations of curses it may be declared differently, we really should use the "chtype" type directly but console.h is also used when the use of curses was disabled in qemu config.
+
+I'm pretty sure the curses support has been tested on machines of both endianness at one point, but mostly with ncurses only.
+
+I just checked out the ncurses source - it looks like the type of "chtype" actually depends on how ncurses is configured at build time:
+
+curses.h.in:
+#if @cf_cv_enable_lp64@ && defined(_LP64)
+typedef unsigned chtype;
+typedef unsigned mmask_t;
+#else
+typedef unsigned @cf_cv_typeof_chtype@ chtype;
+typedef unsigned @cf_cv_typeof_mmask_t@ mmask_t;
+#endif
+
+So even if Qemu targets only ncurses, we can't assume that chtype is anything in particular.
+
+In light of that, I guess this bug boils down to "let's use chtype directly," which (naively) seems like it could be #ifdef'd pretty easily.
+
+This is probably the source of the problem.  As you say it'd be best to use chtype directly if it can be done cleanly, unfortunately it looks like it'll add a curses specific snippet in console.h, but so be it.  The only other option is to add a conversion step in curses.c and give up zero-copy passing screen data to curses, which I'd like to avoid.
+
+How about using CONFIG_CURSES?  If we --enable-curses, then we know we have curses.h and chtype.  If we --disable-curses, then we don't care.
+
+Patch attached.  It's a no-op if curses is disabled, and it fixes the issue on my machine with curses enabled.  I had to undef the color constants from curses.h so we didn't conflict with enum color_names in console.c.
+
+for which version is the last patch?
+also 12.3?
+
+Pretty sure it was the latest Arch package: 0.14.1.  Did you have trouble applying it?
+
+I can run back and make a patch against git if you can't use this.
+
+no I don't believe it was your fault
+I couldn't get the code compile even without your patch...
+
+man this sucks... i had hoped it would be upstream with 0.15 but I might have to try to compile it by myself again
+
+thanks ;)
+
+Alright, I've sent a patch to qemu-devel.  Let's see what happens now...
+
+ahhhh it worked, just tried it with latest stable 0.15 git !!! finally you are my hero! =)
+
+Fix had been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=df00bed0fa30a6f5712
+... so closing this bug ticket now.
+