summary refs log tree commit diff stats
path: root/results/classifier/108/none/159
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/none/15916
-rw-r--r--results/classifier/108/none/1590136
-rw-r--r--results/classifier/108/none/1593605262
-rw-r--r--results/classifier/108/none/159620441
4 files changed, 455 insertions, 0 deletions
diff --git a/results/classifier/108/none/159 b/results/classifier/108/none/159
new file mode 100644
index 00000000..f6816a55
--- /dev/null
+++ b/results/classifier/108/none/159
@@ -0,0 +1,16 @@
+graphic: 0.546
+device: 0.500
+performance: 0.496
+semantic: 0.409
+permissions: 0.258
+network: 0.158
+other: 0.128
+debug: 0.126
+files: 0.084
+socket: 0.062
+vnc: 0.060
+boot: 0.047
+KVM: 0.029
+PID: 0.018
+
+qemu-nbd -l and -s options don't work together
diff --git a/results/classifier/108/none/1590 b/results/classifier/108/none/1590
new file mode 100644
index 00000000..6801e535
--- /dev/null
+++ b/results/classifier/108/none/1590
@@ -0,0 +1,136 @@
+other: 0.565
+graphic: 0.477
+permissions: 0.468
+device: 0.466
+debug: 0.448
+performance: 0.373
+PID: 0.365
+semantic: 0.353
+files: 0.322
+KVM: 0.311
+network: 0.308
+boot: 0.307
+vnc: 0.269
+socket: 0.233
+
+Regression: ARMv8M secure mode debugging non-functional since ~v7.2.0
+Description of problem:
+Prior to qemu commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b, both semihosting printf calls and debugging via gdb work as expected. 
+
+Builds of qemu containing commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b do not produce any semihosting output and are not debuggable via gdb.
+Steps to reproduce:
+1. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.1.0, note the "blinking" print to the console once a second.
+2. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.2.0, note that no messages are printed to the console.
+3. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf -S -s`` and attach gdb with the following gdbinit file.
+Additional information:
+Log of successful gdb session with the attached patch on top of qemu master branch:
+```
+% arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf
+GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git
+Copyright (C) 2023 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.linaro.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from build/mps2_an505_cm33_blink_demo.elf...
+The target architecture is set to "armv8-m.main".
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172
+172     {
+Section .privileged_functions, range 0x10000000 -- 0x10008000: matched.
+Section .text, range 0x10008000 -- 0x10019c18: matched.
+Section .rodata, range 0x10019c18 -- 0x1001b270: matched.
+Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: matched.
+Section .copy.table, range 0x1001b278 -- 0x1001b284: matched.
+Section .data, range 0x1001b28c -- 0x1001bb90: matched.
+Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: matched.
+Section .zero.table, range 0x1001b284 -- 0x1001b28c: matched.
+Breakpoint 1 at 0x10009900: file /FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494.
+(gdb) s
+174         asm volatile
+(gdb) s
+189         init_data_sections();
+(gdb) s
+init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99
+99          for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ )
+(gdb) s
+101             for( dataIndex = 0; dataIndex < pCopyTable->uxLen; dataIndex++ )
+(gdb) info locals
+pCopyTable = 0x1001b278
+dataIndex = 0
+(gdb) print /x *0xE000ED08
+$1 = 0x10000000
+```
+
+Log of an unsuccessful gdb session with qemu v7.2.0
+```
+pbartell@147dda7342a9 ARM_MPS % arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf
+GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git
+Copyright (C) 2023 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.linaro.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from build/mps2_an505_cm33_blink_demo.elf...
+The target architecture is set to "armv8-m.main".
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172
+172     {
+Section .privileged_functions, range 0x10000000 -- 0x10008000: MIS-MATCHED!
+Section .text, range 0x10008000 -- 0x10019c18: MIS-MATCHED!
+Section .rodata, range 0x10019c18 -- 0x1001b270: MIS-MATCHED!
+Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: MIS-MATCHED!
+Section .copy.table, range 0x1001b278 -- 0x1001b284: MIS-MATCHED!
+Section .data, range 0x1001b28c -- 0x1001bb90: MIS-MATCHED!
+Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: MIS-MATCHED!
+Section .zero.table, range 0x1001b284 -- 0x1001b28c: MIS-MATCHED!
+warning: One or more sections of the target image does not match
+the loaded file
+
+Breakpoint 1 at 0x10009900: file /FreeRTOS/FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494.
+(gdb) s
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:174
+174         asm volatile
+(gdb) s
+Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:189
+189         init_data_sections();
+(gdb) s
+init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:95
+95      {
+(gdb) s
+init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99
+99          for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ )
+(gdb) info locals
+pCopyTable = <error reading variable pCopyTable (Cannot access memory at address 0x381fffdc)>
+dataIndex = <error reading variable dataIndex (Cannot access memory at address 0x381fffd8)>
+(gdb) print /x *0xE000ED08
+$1 = 0x0
+(gdb) quit
+```
+
+.gdbinit file:
+```
+set architecture armv8-m.main
+target extended-remote :1234
+compare-sections
+break HardFault_Handler
+```
+
+[mps2_an505_cm33_blink_demo.elf](/uploads/c86e086b00651a8d5392857b9e4a2c4d/mps2_an505_cm33_blink_demo.elf)
+[target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch](/uploads/5735d5f7d7b15dbbeb0c2d214a46c1a8/target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch)
diff --git a/results/classifier/108/none/1593605 b/results/classifier/108/none/1593605
new file mode 100644
index 00000000..efb4ab08
--- /dev/null
+++ b/results/classifier/108/none/1593605
@@ -0,0 +1,262 @@
+permissions: 0.428
+KVM: 0.400
+other: 0.400
+vnc: 0.388
+boot: 0.333
+device: 0.331
+network: 0.329
+semantic: 0.313
+files: 0.308
+socket: 0.300
+debug: 0.299
+performance: 0.298
+graphic: 0.296
+PID: 0.274
+
+windows2008r2 boot failed with uefi
+
+I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my qemu command line show below:
+
+qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-i440fx-2.5,accel=kvm,usb=off -cpu host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1 -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp 8,maxcpus=96,sockets=24,cores=4,threads=1 -numa node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win2008r2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x5 -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on
+
+
+OVMF.fd is download from http://sourceforge.net/projects/edk2/files/OVMF/ OVMF-X64-r15214.zip.
+
+When I boot my domain with windows2008 iso, the kvm was caught in endless interrupt. I enable trace on my host and I got this.
+
+
+
+1. echo 1 > /sys/kernel/debug/tracing/events/kvm/enable
+2. cat /sys/kernel/debug/tracing/trace_pipe 
+qemu-system-x86-1969  [006] ....  2093.019588: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.019590: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.021424: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.021429: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.021430: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.021683: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.021686: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.022592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef
+ qemu-system-x86-1969  [006] d...  2093.022595: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.022746: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.022749: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.023434: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.023444: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.023446: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.023610: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.023612: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.025430: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.025435: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.025436: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.025599: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.025601: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] .N..  2093.026593: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef
+ qemu-system-x86-1969  [006] d...  2093.026596: kvm_fpu: unload
+ qemu-system-x86-1969  [006] ....  2093.026598: kvm_ple_window: vcpu 0: ple_window 4096 (shrink 4096)
+ qemu-system-x86-1969  [006] ....  2093.026599: kvm_fpu: load
+ qemu-system-x86-1969  [006] d...  2093.026599: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.026741: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.026744: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.026841: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.026844: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.027448: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.027454: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.027455: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1966  [017] ....  2093.029444: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.029449: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.029450: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.029452: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef
+ qemu-system-x86-1969  [006] d...  2093.029454: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.029633: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.029636: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.030592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000ef
+ qemu-system-x86-1969  [006] d...  2093.030595: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.030745: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.030748: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.030840: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.030843: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.031454: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.031459: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.031460: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1966  [017] ....  2093.032968: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.032974: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.032975: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.033229: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.033231: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.034592: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000ef
+ qemu-system-x86-1969  [006] d...  2093.034595: kvm_entry: vcpu 0
+ qemu-system-x86-1969  [006] ....  2093.034781: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.034783: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.034975: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.034980: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.034981: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.035113: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae8e info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.035116: kvm_entry: vcpu 0
+ qemu-system-x86-1966  [017] ....  2093.036983: kvm_set_irq: gsi 8 level 1 source 0
+ qemu-system-x86-1966  [017] ....  2093.036989: kvm_pic_set_irq: chip 1 pin 0 (edge|masked)
+ qemu-system-x86-1966  [017] ....  2093.036990: kvm_ioapic_set_irq: pin 8 dst 1 vec=209 (Fixed|logical|edge) (coalesced)
+ qemu-system-x86-1969  [006] ....  2093.037154: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xfffff8001080ae78 info 0 800000fd
+ qemu-system-x86-1969  [006] d...  2093.037157: kvm_entry: vcpu 0
+
+
+
+The OVMF build you use (SVN r15214) is from Feb 2014 -- it is completely obsolete. I suggest you use the packages from https://www.kraxel.org/repos/ .
+
+I'm marking this as "invalid" because supporting 2+ year old OVMF builds is unthinkable.
+
+Thanks for your advice. I got newer version of OVMF from https://www.kraxel.org/repos/. And compile from source code(git://github.com/tianocore/edk2.git). 
+With these OVMF, it really works well on only 1 vcpu domain. But still failed with multi-vcpus. 
+The vcpu0 runnig in an endless loop, and other vcpus is halted. The stack of vcpu0 show below:
+#0  0x00005571f4b10959 in address_space_update_topology_pass (as=0x5571f6b76de8, old_view=0x7f6884020690, new_view=0x7f6884022ab0, adding=true)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:753
+#1  0x00005571f4b10a18 in address_space_update_topology (as=0x5571f6b76de8) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:768
+#2  0x00005571f4b10bba in memory_region_transaction_commit () at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:809
+#3  0x00005571f4b13d8b in memory_region_update_container_subregions (subregion=0x5571f6cc5140)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1658
+#4  0x00005571f4b13e14 in memory_region_add_subregion_common (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1668
+#5  0x00005571f4b13ee8 in memory_region_add_subregion_overlap (mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140, priority=2)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1687
+#6  0x00005571f4b2c27a in vga_update_memory_access (s=0x5571f6cc4f38) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:210
+#7  0x00005571f4b2cddb in vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:538
+#8  0x00005571f4cf7072 in qxl_vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, val=8) at hw/display/qxl.c:1197
+#9  0x00005571f4b03316 in portio_write (opaque=0x5571f6c72890, addr=14, data=2056, size=2)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/ioport.c:201
+#10 0x00005571f4b0ea9c in memory_region_write_accessor (mr=0x5571f6c72890, addr=14, value=0x7f688b73ab28, size=2, shift=0, mask=65535)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:444
+#11 0x00005571f4b0ebe4 in access_with_adjusted_size (addr=14, value=0x7f688b73ab28, size=2, access_size_min=1, access_size_max=4, 
+    access=0x5571f4b0ea00 <memory_region_write_accessor>, mr=0x5571f6c72890) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:481
+#12 0x00005571f4b11b28 in memory_region_dispatch_write (mr=0x5571f6c72890, addr=14, data=2056, size=2)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1138
+#13 0x00005571f4b152ce in io_mem_write (mr=0x5571f6c72890, addr=14, val=2056, size=2) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1971
+#14 0x00005571f4abd56b in address_space_rw (as=0x5571f5333b80, addr=974, buf=0x7f689a390000 "\b", <incomplete sequence \307>, len=2, is_write=true)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/exec.c:2123
+#15 0x00005571f4b0b028 in kvm_handle_io (port=974, data=0x7f689a390000, direction=1, size=2, count=1)
+    at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1616
+#16 0x00005571f4b0b5d1 in kvm_cpu_exec (cpu=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1758
+#17 0x00005571f4af0bf0 in qemu_kvm_cpu_thread_fn (arg=0x5571f6a5d5e0) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/cpus.c:898
+#18 0x00007f6899c18e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
+#19 0x00007f68963f938d in clone () from /lib/x86_64-linux-gnu/libc.so.6
+#20 0x0000000000000000 in ?? ()
+
+
+When I change qemu version from 2.1.2 to 2.6.0. The vcpu0 will return 0 qemu.
+I got strace like this:
+strace -p 1180
+Process 1180 attached - interrupt to quit
+rt_sigtimedwait([BUS USR1], 0x7f719b5fa960, {0, 0}, 8) = -1 EAGAIN (Resource temporarily unavailable)
+rt_sigpending([])                       = 0
+futex(0x55669f356d60, FUTEX_WAKE_PRIVATE, 1) = 1
+ioctl(26, KVM_RUN
+
+The kvm tracing like this:
+             kvm-1180  [018] d... 63148.545821: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.545944: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.545948: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546083: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546085: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546200: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546202: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546317: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546320: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546436: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546439: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546553: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546556: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546689: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546691: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546807: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546810: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.546927: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.546930: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.547067: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.547070: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.547186: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.547189: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.547304: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000fd
+             kvm-1180  [018] d... 63148.547307: kvm_entry: vcpu 0
+             kvm-1180  [018] d... 63148.547384: kvm_exit: reason EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 800000ef
+             kvm-1180  [018] d... 63148.547391: kvm_entry: vcpu 0
+
+
+Win2k8 EFI has a bug under HyperV. This will never work without a specific hack in UEFI. I can dig in my archives to find a patch if you are really interested in. AFAIR some memory in video driver has to be marked not as boot services but differently and will stay permanently.
+
+Hi Denis, thank you very much. I do really be interested in it. If the patch can be found, it readlly help me. 
+
+And I still have another question. I notice that Win2k8 cound runnig with UEFI normally on Xen and VMare. Is there any diffrence between them abount handling with video, especially on Xen enviroment？
+
+Thank you very much!
+
+you CAN run, but you have to disable HyperV enlightments. This means that these options "hv_time,hv_relaxed,hv_spinlocks=0x2000" must NOT be set.
+
+I have not found exact patch, sorry. But something like the following should be done even to start thinking on running win2k8 with EFI if HyperV is enabled. Look into OvmfPkg/QemuVideoDxe/ and replace allocations of EfiBootServicesData/EfiBootServicesCode with EfiACPIMemoryNVS.
+
+For our case we have found that "The problem is triggered by the Windows memory manager unmapping the page #0 while Windows HAL keeps thinking it's still available and accesses it.
+
+The unmapping happens because the page #0 is marked by OVMF as EfiBootServicesCode.
+
+Reportedly the access of the page #0 by HAL only happens when the VM announces
+the support for Hyper-V enlightenments; otherwise no crashes are observed."
+
+Thank you very much. After disabling all HyperV feature, Win2k8 can runnig with multi-vcpus in my enviroment. 
+
+Referring to your advice, I will try to runnig Win2k8 with HyperV feature. Thank you very much.
+
+
+
+Denis, thanks a lot for the reminder and the analysis here. I knew about this issue at one point -- see https://bugzilla.redhat.com/show_bug.cgi?id=1185253 -- but by now I've completely forgotten that HyperV enlightenments and UEFI SMP Win7 don't mix.
+
+Also, for your analysis in comment #7 -- thanks for that too; I've never dug into it this deep. In the RHBZ I referenced above, there's a link to MSDN -- https://technet.microsoft.com/en-us/library/dn282285.aspx -- which indicates that the UEFI Win7 family was never meant to be run as HyperV guests. Those docs were enough explanation to me.
+
+I don't think hacking on OVMF's VBE shim would be smart at this point -- the VBE shim is already an ugly hack to trick Win7 into working. I think the best course of action here is to disable HyperV enlightenments for Win7 UEFI guests. That's what virt-manager does as well:
+
+https://github.com/virt-manager/virt-manager/commit/cbba1c4dd381
+
+Given that this is not a QEMU issue, I'm closing the report (again).
+
+Actually I can provide you with the patch which makes win2k8 + UEFI working if you willing to accept it for mainstream QEMU. It was quite simple. We have prepared it but not sent. Parallels Server 6/Parallels Desktop have this hack around 3-5 years.
+
+I have missed you comment. Closing again.
+
+sorry, I meant not QEMU but UEFI above.
+
+... In addition to what I said above in comment #9 (which stands), the technical problem with turning the memory allocation in question into AcpiNVS type is that it would prevent *all* OSes from reusing the area.
+
+It would prevent the Windows 7 memory manager from deallocating page #0 (thereby saving Windows 7 HAL's buttocks), correct, but the page would also be lost for other, actually UEFI-abiding, OSes as well. That's a way too high price to pay for bug-compatibility with Windows 7.
+
+This is actually documented in the commit message of https://github.com/tianocore/edk2/commit/90803342b1b6 . An excerpt:
+
+    The Int10h real-mode IVT entry is covered with a Boot Services Code page,
+    making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes
+    different from the Windows 2008 family can reclaim the page. The Windows
+    2008 family accesses the page at zero regardless of the allocation type.)
+
+This was in fact a difference between v1 and v2 of the patch. V1 used EfiReservedMemoryType, but v2 changed that, so that no other OSes would be punished. See esp. the Notes section of v2:
+
+http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7047
+http://thread.gmane.org/gmane.comp.bios.tianocore.devel/7127
+
+
+I had the same problem and it took me some time to get to this bug report.
+
+Since this behaviour will not change in future versions of Qemu/OVMF, maybe Qemu should recognize this configuration as invalid and print error message instead of failing silently?
+
+@alex3kov -- I think you mean the question as
+
+"""
+Since this behaviour will not change in future versions of Windows 7 / Windows Server 2008 R2, ...
+"""
+
+because, again, the problem is not in OVMF but in the Windows guest.
+
+QEMU cannot be expected to recognize (guest OS, guest firmware, hw config) combinations that might not work. That's not QEMU's business.
+
+Such (automatic or semi-automatic) config tweaks belong to the management layer. If you use virt-manager or virt-install to create your guest, and select the guest OS type correctly (or let virt-manager / virt-install recognize the guest type from a signature of the installer ISO, which I believe is implemented with the help of libosinfo), then virt-manager / virt-install will automatically disable Hyper-V enlightments for you. This is what https://bugzilla.redhat.com/show_bug.cgi?id=1185253 was about, which I referenced here earlier.
+
+The virt-manager change is <https://github.com/virt-manager/virt-manager/commit/cbba1c4dd3815e3981d3b315bf28d1018f838702>.
+
+So, the answer to your question is to use libvirt and its tools (which is recommended anyway). Thanks.
+
+(In general, I have no idea why large groups of users keep struggling with QEMU command lines, when the interface that libvirt provides is just so much better and easier for production use. The reason I always recommend libvirt is not because I'm an RH zealot, the reason I recommend it is that libvirt adds *actual value*, even for the individual, interactive user.)
+
+
diff --git a/results/classifier/108/none/1596204 b/results/classifier/108/none/1596204
new file mode 100644
index 00000000..8e817c85
--- /dev/null
+++ b/results/classifier/108/none/1596204
@@ -0,0 +1,41 @@
+device: 0.551
+other: 0.531
+performance: 0.522
+graphic: 0.321
+semantic: 0.304
+debug: 0.303
+permissions: 0.293
+network: 0.270
+PID: 0.235
+boot: 0.163
+socket: 0.161
+vnc: 0.134
+files: 0.048
+KVM: 0.016
+
+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.
+
+