3 files changed, 190 insertions, 0 deletions
diff --git a/results/classifier/118/none/498 b/results/classifier/118/none/498
new file mode 100644
index 00000000..d0ac657f
--- /dev/null
+++ b/results/classifier/118/none/498
@@ -0,0 +1,72 @@
+KVM: 0.394
+user-level: 0.387
+TCG: 0.341
+ppc: 0.321
+VMM: 0.309
+hypervisor: 0.288
+mistranslation: 0.287
+vnc: 0.283
+risc-v: 0.279
+x86: 0.278
+graphic: 0.261
+peripherals: 0.232
+register: 0.222
+i386: 0.187
+virtual: 0.180
+permissions: 0.179
+architecture: 0.148
+performance: 0.144
+boot: 0.133
+assembly: 0.125
+arm: 0.122
+device: 0.118
+semantic: 0.109
+debug: 0.099
+network: 0.085
+files: 0.084
+PID: 0.078
+kernel: 0.069
+socket: 0.068
+
+Cannot focus QEMU window on macOS Big Sur (11.4)
+Description of problem:
+I'm not sure when the problem has been started, but I recently noticed that key inputs to QEMU window are not processed and the input goes other focused windows (e.g. terminal). QEMU window itself is shown but it looks like they are not focused. Also, the Dock icon for QEMU is also disappeared (it was displayed before).
+Steps to reproduce:
+1. build & install the latest qemu with `./configure --target-list=x86_64-softmmu` 
+    - (`a146af86c8247f41b641783428b95ee71eb0e43f` was the revision I used)
+2. run　`qemu-system-x86_64` from terminal
+3. click the QEMU window.
+    - Expected behavior: menu bar title will be switched to "QEMU", key inputs are handled by QEMU, Dock icon will be shown.
+    - Actual behavior: menu bar shows different app name that were focused before clicking the qemu, key inputs went to other app that was focused, dock icon is not showing up.
+Additional information:
+I tried to see if the events are delivered to QemuCocoaView by putting `NSLog(@"handleEventLocked: %@\n", event);` at the beginning of `handleEventLocked` @ `ui/cocoa.m`. It looks like the mouse events are delivered but not NSEventTypeKeyDown.
+
+(logs after clicked the QEMU window and type some 'a')
+```
+$ qemu-system-x86_64 
+2021-07-24 16:58:00.767 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682409.7 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=4 data1=1144258560 data2=1138098176
+2021-07-24 16:58:00.768 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,228) time=682409.7 flags=0 win=0x7fe2b5fb0ee0 winNum=10356 ctxt=0x0 subtype=4 data1=1137180672 data2=1130627072
+2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1129 data2=0
+2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(591.031,166.896) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0![スクリーンショット_2021-07-24_16.51.53](/uploads/7e9b0987b70a776976541d5320f66a0d/スクリーンショット_2021-07-24_16.51.53.png)x0 evNum=6096 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0
+2021-07-24 16:58:06.462 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,0) time=0.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=1 data1=1129 data2=0
+2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=22 data1=0 data2=0
+2021-07-24 16:58:06.487 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682415.4 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=23 data1=0 data2=0
+2021-07-24 16:58:06.565 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(591.031,166.896) time=682415.5 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6096 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0
+2021-07-24 16:58:12.997 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(174.184,408.859) time=682421.9 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+2021-07-24 16:58:13.013 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(152.704,428.804) time=682422.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=Kitdefined loc=(0,428) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 subtype=9 data1=1131 data2=0
+2021-07-24 16:58:24.181 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(268.333,208.222) time=682433.1 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0
+2021-07-24 16:58:24.262 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(268.333,208.222) time=682433.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6098 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0
+2021-07-24 16:58:24.877 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(3.83252,400.359) time=682433.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+2021-07-24 16:58:25.053 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1
+2021-07-24 16:58:25.054 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseEntered loc=(7.08813,408.091) time=682434.0 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0
+2021-07-24 16:58:25.302 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseDown loc=(10.917,420.558) time=682434.2 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=1 deviceID:0x0 subtype=0
+2021-07-24 16:58:25.365 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=LMouseUp loc=(10.917,420.558) time=682434.3 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=6099 click=1 buttonNumber=0 pressure=0 deviceID:0x0 subtype=0
+2021-07-24 16:58:25.845 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe295c0f090 userData=0x1
+2021-07-24 16:58:25.846 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(11.9221,422.759) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e80e30 userData=0x0
+2021-07-24 16:58:25.855 qemu-system-x86_64[3752:7837649] handleEventLocked: NSEvent: type=MouseExited loc=(14.2417,428.558) time=682434.8 flags=0 win=0x7fe2b5e48960 winNum=10355 ctxt=0x0 evNum=0 trackNum=7fe2b5e81d60 userData=0x0
+
+```
+
+Possibly related discussion on Apple Developer Forums:
+- https://developer.apple.com/forums/thread/667004
diff --git a/results/classifier/118/none/498039 b/results/classifier/118/none/498039
new file mode 100644
index 00000000..5d1cea7b
--- /dev/null
+++ b/results/classifier/118/none/498039
@@ -0,0 +1,48 @@
+device: 0.575
+graphic: 0.476
+vnc: 0.330
+i386: 0.280
+semantic: 0.258
+network: 0.252
+ppc: 0.248
+PID: 0.229
+x86: 0.228
+virtual: 0.210
+user-level: 0.196
+risc-v: 0.182
+mistranslation: 0.158
+socket: 0.148
+register: 0.145
+architecture: 0.139
+arm: 0.134
+VMM: 0.126
+hypervisor: 0.117
+debug: 0.102
+kernel: 0.093
+TCG: 0.092
+permissions: 0.091
+performance: 0.091
+boot: 0.072
+files: 0.069
+assembly: 0.058
+peripherals: 0.055
+KVM: 0.053
+
+No copy/paste with VNC display with Windows guest
+
+There is no copy/paste functionality between a Windows guest and the VNC client.  This is a significant usability problem.
+
+One work-around is to run VNC inside of the guest.  But that appears to have more overhead than qemu's VNC display.
+
+Obviously, qemu's VNC display is just a display device and knows absolutely nothing about the Windows clipboard.  Thus, to interface with the guest's clipboard would require a helper app running in the guest that can hook into qemu.  This would probably be the best solution.
+
+There are probably not a lot of qemu developers interested in trying to write the helper app.  Not exactly an interesting job.  But since it is a significant usability problem, and many users would see this as a major oversight, I suggest leaving this bug open long-term as a hint so that some volunteer later looking for something to do might take pity on everyone and write this helper app.
+
+The qxl display and vdagent running in guest do just this.
+
+Unfortunately, the options needed in qemu command line to make vdagent work with the spice client do not seem to be documented anywhere.
+
+see bug 1452742
+
+Right, this problem should be fixed with Spice, so I'm closing this ticket now.
+
diff --git a/results/classifier/118/none/498417 b/results/classifier/118/none/498417
new file mode 100644
index 00000000..b6c4fdd1
--- /dev/null
+++ b/results/classifier/118/none/498417
@@ -0,0 +1,70 @@
+performance: 0.748
+architecture: 0.578
+user-level: 0.484
+permissions: 0.461
+device: 0.451
+register: 0.440
+PID: 0.438
+assembly: 0.427
+kernel: 0.415
+graphic: 0.413
+semantic: 0.411
+vnc: 0.385
+hypervisor: 0.384
+virtual: 0.384
+peripherals: 0.382
+network: 0.363
+ppc: 0.354
+socket: 0.350
+x86: 0.344
+files: 0.343
+mistranslation: 0.337
+arm: 0.336
+risc-v: 0.308
+i386: 0.308
+debug: 0.292
+KVM: 0.291
+VMM: 0.279
+TCG: 0.278
+boot: 0.268
+
+cache=writeback on disk image doesn't do write-back
+
+I noticed that qemu seems to have poor disk performance.  Here's a test that has miserable performance but which should be really fast:
+
+- Configure qemu to use the disk image with cache=writeback
+- Configure a 2GiB Linux VM on an 8GiB Linux host
+- In the VM, write a 4GiB file (dd if=/dev/zero of=/tmp/x bs=4K count=1M)
+- In the VM, read it back (dd if=/tmp/x of=/dev/null bs=4K count=1M)
+
+With writeback, the whole file should end up in the host pagecache.  So when I read it back, there should be no I/O to the real disk, and it should be really fast.  Instead, I see disk activity through the duration of the test, and the performance is roughly the native hard disk throughput (somewhat slower).
+
+I'm using version 0.11.1, and this is my command line:
+
+qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -enable-kvm &
+
+Can you please try reproducing with 0.12.1?
+
+I'm using 0.12.1.2.  With this command line:
+
+qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm &
+
+Here's what I'm seeing:
+
+With "dd if=/dev/zero of=./x bs=1024k count=1024", I get at best 29 MiB/sec.  
+
+This fits in the VM, so with "dd if=/dev/zero of=./x bs=1024k count=1024", which spills into the host, I get at best 25 MiB/sec.  (I am aware that with the expanding qcow2 disk image, there's also some overhead for allocating space during the write, so I run the same test multiple times and report the best result.)
+
+Since I'm using writeback, I would expect to see much faster write performance.  This is slower than the host's disk performance with fsync involved.  Is there an fsync going on here?  Is dd doing an fsync?  That should sync the VM's disk.  But then is there an ATA command to sync the drive that qemu interprets as a request to sync the disk image?  It would be "safe" to take this hint, but since I'm explicitly requesting writeback, I'm not expecting "safe".  I'm intentionally defeating "safe" for the sake of performance, with full knowledge of the risks.
+
+With "dd if=./x of=/dev/null bs=1024k count=1024", it varies a LOT, but I've gotten as much as 4.9GiB/sec and as little as 2.5GiB/sec.  This is WAY better than what I was getting with 0.11.1.
+
+With "dd if=./x of=/dev/null bs=1024k count=4096", the best I get is 460MiB/sec.  That's still very good.  Could be better, but the overhead of emulating SATA has got to be really high under any circumstances.
+
+Using a VM imposes a lot of overhead that makes the guest OS quite a bit slower than running it directly on the hardware.  I'm trying to make up for this by using the rest of my hosts RAM (more or less) as a huge disk cache.
+
+
+QEMU 0.11 / 0.12 is pretty much outdated nowadays ... can you still reproduce this issue with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+