diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/118/all/1703 | 75 | ||||
| -rw-r--r-- | results/classifier/118/all/1703506 | 259 | ||||
| -rw-r--r-- | results/classifier/118/all/1703795 | 96 |
3 files changed, 430 insertions, 0 deletions
diff --git a/results/classifier/118/all/1703 b/results/classifier/118/all/1703 new file mode 100644 index 00000000..32699dae --- /dev/null +++ b/results/classifier/118/all/1703 @@ -0,0 +1,75 @@ +semantic: 0.947 +permissions: 0.942 +mistranslation: 0.935 +arm: 0.926 +performance: 0.921 +architecture: 0.918 +debug: 0.916 +graphic: 0.914 +user-level: 0.910 +assembly: 0.907 +register: 0.903 +risc-v: 0.901 +TCG: 0.900 +device: 0.900 +virtual: 0.892 +PID: 0.889 +peripherals: 0.865 +kernel: 0.861 +VMM: 0.859 +ppc: 0.851 +network: 0.846 +socket: 0.837 +boot: 0.837 +hypervisor: 0.832 +KVM: 0.831 +vnc: 0.809 +x86: 0.803 +files: 0.758 +i386: 0.728 + +Undefined behaviour when running guest with -enable-kvm and attached debugger +Description of problem: +When attaching a debugger to a Qemu instance with `-enable-kvm` my linux kernel panics on (f.e.) module load. +I am not sure if this is a Qemu bug, however the issue is not occurring if I a) do not attach the debugger (even though Qemu is listening for one) or b) I do not pass `-enable-kvm` (and attach a debugger). +The issue seems to relate to the `lx-symbols` command provided by the Linux kernel gdb script suite. +Every time a module is loaded this script will reload the symbols for said module which may take some time, so maybe there is some race involved? +The issue does not reproduce if you do not run `lx-symbols` prior to continuing (it will however run automatically after first module load as it adds a breakpoint to kernel/module/main.c:do_init_module, so the kernel will crash after the second module load) +Steps to reproduce: +1. Start kernel with some img +2. Attach gdb debugger +3. Run the `lx-symbols` command provided by the Linux kernel gdb scripts in gdb, run `continue` in gdb +3. Load a kernel module +Additional information: +This is the kernel stack trace: +``` +[ 22.930691] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 22.931174] CPU: 2 PID: 241 Comm: modprobe Tainted: G E 6.1.31+ #2 +[ 22.931675] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 +[ 22.931675] RIP: 0010:do_init_module+0x1/0x210 +[ 22.931675] Code: 74 0c 48 8b 78 08 48 89 de e8 8b df ff ff 65 ff 0d 84 94 ef 7e 0f 85 e5 fe ff ff 0f 1f 44 00 008 +[ 22.931675] RSP: 0018:ffffc90000593e40 EFLAGS: 00010246 +[ 22.931675] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000006e202 +[ 22.931675] RDX: 000000000006e002 RSI: 5b4504de76578f76 RDI: ffffffffc024e180 +[ 22.931675] RBP: ffffc90000593e50 R08: ffffea0000174a88 R09: ffffea0000174ac0 +[ 22.931675] R10: ffff888006a9c270 R11: 0000000000000100 R12: 0000562f9087b4a0 +[ 22.931675] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 22.931675] FS: 00007f0dbc5a4040(0000) GS:ffff88801f500000(0000) knlGS:0000000000000000 +[ 22.931675] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 22.931675] CR2: 00007ffdc94bc3f8 CR3: 0000000006f8e000 CR4: 00000000003506e0 +[ 22.931675] Call Trace: +[ 22.931675] <TASK> +[ 22.931675] ? die+0x32/0x80 +[ 22.931675] ? do_trap+0xd6/0x100 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] ? do_error_trap+0x6a/0x90 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] ? exc_invalid_op+0x4c/0x60 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] ? asm_exc_invalid_op+0x16/0x20 +[ 22.931675] ? do_init_module+0x1/0x210 +[ 22.931675] __do_sys_finit_module+0x9e/0xf0 +[ 22.931675] do_syscall_64+0x63/0x90 +[ 22.931675] ? exit_to_user_mode_prepare+0x1a/0x120 +[ 22.931675] entry_SYSCALL_64_after_hwframe+0x63/0xcd +``` diff --git a/results/classifier/118/all/1703506 b/results/classifier/118/all/1703506 new file mode 100644 index 00000000..6991f1b4 --- /dev/null +++ b/results/classifier/118/all/1703506 @@ -0,0 +1,259 @@ +debug: 0.951 +graphic: 0.947 +semantic: 0.946 +register: 0.938 +virtual: 0.938 +network: 0.937 +peripherals: 0.926 +performance: 0.925 +hypervisor: 0.924 +permissions: 0.920 +VMM: 0.911 +device: 0.905 +assembly: 0.901 +architecture: 0.898 +boot: 0.897 +socket: 0.894 +arm: 0.887 +KVM: 0.883 +vnc: 0.881 +risc-v: 0.878 +files: 0.874 +PID: 0.873 +kernel: 0.873 +x86: 0.867 +mistranslation: 0.860 +user-level: 0.844 +TCG: 0.839 +ppc: 0.808 +i386: 0.732 + +SMT not supported by QEMU on AMD Ryzen CPU + +HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this message when setting the topology to threads=2: + +qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly. + +Checking in a Windows 10 guest reveals that SMT is not enabled, and from what I understand, QEMU converts the topology from threads to cores internally on AMD CPUs. This appears to cause performance problems in the guest perhaps because programs are assuming that these threads are actual cores. + +Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro guest + +I can confirm this problem as it affects me, too on Ubuntu XENIAL, Kernel 4.10.0-26-generic + +The warning doesn't make QEMU disable anything, it just warns the user that guests are likely to ignore the HT info on CPUID if CPU vendor is AMD. + +Please confirm what's the QEMU command-line being used (especially the -smp and -cpu options), and check if the bug persists if using "-cpu host". + +To help find out what's wrong, I'd like to see /proc/cpuinfo, "lscpu -e" output and "x86info -v -a" output from both the host system and the guest system. + +>Please confirm what's the QEMU command-line being used (especially the -smp and -cpu options), and check if the bug persists if using "-cpu host". + +I'm using -cpu host already, here's just the cpu and smp commands: + +-cpu host,hv_vendor_id=whatever,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,smep=off +-smp 12,sockets=1,cores=6,threads=2 + +The extra commands are just for VGA passthrough, but the problem still occurs with just -cpu host (plus smep=off, problems with booting with it enabled) and the above smp setting. + +I've attached host output; I'm using a Windows guest and running msinfo32 indicates: + +AMD Ryzen 1600 Six-Core Processor, 3693 Mhz, 12 Core(s), 12 Logical Processors(s) + +Suggesting that the guest is seeing the host as 12 cores, 1 thread each, rather than 6 cores, 2 threads each. + +If Linux guest information would be more helpful, I'll set up a Linux guest as well. + +I can confirm the same behavior with a Ryzen 7 1700. +Host Arch Linux x64 Kernel 4.11.9, Guest Windows 10 Pro. +Running with -cpu host and -smp 8,sockets=1,cores=4,threads=2. +Attached the logs of the host and results of the output of msinfo32 and "WMIC CPU Get NumberOfCores,NumberOfLogicalProcessors /Format:List" in the guest. +Same results as scix, in my case 8 Core(s), 8 Logical Processors(s). + +This seems relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1135772 +And a few extra reports on reddit: +https://www.reddit.com/r/VFIO/comments/6nuhb5/big_problem_with_my_ryzen_1700x/ +https://www.reddit.com/r/VFIO/comments/6m6kry/smthyperthreading_support_with_ryzen_cpu_and/ + +I'll test with a Linux guest later. + +Thank you for the info. Having info on Linux guests' behavior would be nice to have, but it's possible to extract the raw CPUID data seen by the Windows guest using an equivalent Windows tool (suggestions of tools are welcome). + +Also, can somebody confirm if the same Windows version works as expected on bare metal? + +Attached Ubuntu 17.04 guest logs. +I wasn't able to run x86info as root. Only as regular user. +Error shown: +readEntry: Operation not permitted +error reading 1KB from 0x3fffc00 + +There are a few bug reports about it but no workarounds. Seems to happen on vm's. +So the output is missing a few sections. + +>Also, can somebody confirm if the same Windows version works as expected on bare metal? + +Yes, same Windows version on bare metal works as expected. In my case showing 8 cores and 16 threads/logical processors. +I'm trying to use 4 cores 8 threads in the VMs. Both Windows and Ubuntu are showing 8 physical cores. + +I tried disabling the CmpLegacy bit directly on /target/i386/cpu.c deleting the If statement on "case 0x80000001:" or changing "*ecx |= 1 << 1;" to "*ecx |= 0 << 1;" +But it didn't work, the VM still sees 8 physical cores. +I believe the HTT bit should be enabled by default +I tried changing it to "*edx |= 1 << 28;" in the If statement of "case 1:" just in case but it didn't matter. +Anything else that I could try to hard-code for testing? + +I am looking at the diff between the host and guest CPUID, and we have a few candidates: CPUID[4] is all zeroes on the host, and the host has CPUID leaves up to 0x8000001f available, including CPUID[0x8000001d] (which contains cache topology information). Probably we need to implement CPUID[0x8000001d], I will take a look at Linux code to find out if that's all we need. + +Full CPUID diff below: + +--- /tmp/host-x86info.txt 2017-07-25 15:01:26.753304233 -0300 ++++ /tmp/guest-x86info.txt 2017-07-25 15:01:33.563335744 -0300 +@@ -1,29 +1,29 @@ + eax in: 0x00000000, eax = 0000000d ebx = 68747541 ecx = 444d4163 edx = 69746e65 +-eax in: 0x00000001, eax = 00800f11 ebx = 00100800 ecx = 7ed8320b edx = 178bfbff +-eax in: 0x00000002, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x00000001, eax = 00800f11 ebx = 00080800 ecx = ffd83203 edx = 178bfbff ++eax in: 0x00000002, eax = 00000001 ebx = 00000000 ecx = 0000004d edx = 002c307d + eax in: 0x00000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x00000004, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x00000005, eax = 00000040 ebx = 00000040 ecx = 00000003 edx = 00000000 +-eax in: 0x00000006, eax = 00000004 ebx = 00000000 ecx = 00000001 edx = 00000000 +-eax in: 0x00000007, eax = 00000000 ebx = 209c01a9 ecx = 00000000 edx = 00000000 ++eax in: 0x00000004, eax = 0c000121 ebx = 01c0003f ecx = 0000003f edx = 00000001 ++eax in: 0x00000005, eax = 00000000 ebx = 00000000 ecx = 00000003 edx = 00000000 ++eax in: 0x00000006, eax = 00000004 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x00000007, eax = 00000000 ebx = 209c01ab ecx = 00000000 edx = 00000000 + eax in: 0x00000008, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x00000009, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x0000000a, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x0000000b, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x0000000b, eax = 00000001 ebx = 00000002 ecx = 00000100 edx = 00000000 + eax in: 0x0000000c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x0000000d, eax = 00000007 ebx = 00000340 ecx = 00000340 edx = 00000000 + +-eax in: 0x80000000, eax = 8000001f ebx = 68747541 ecx = 444d4163 edx = 69746e65 +-eax in: 0x80000001, eax = 00800f11 ebx = 20000000 ecx = 35c233ff edx = 2fd3fbff ++eax in: 0x80000000, eax = 8000001a ebx = 68747541 ecx = 444d4163 edx = 69746e65 ++eax in: 0x80000001, eax = 00800f11 ebx = 00000000 ecx = 000003f3 edx = 2fd3fbff + eax in: 0x80000002, eax = 20444d41 ebx = 657a7952 ecx = 2037206e edx = 30303731 + eax in: 0x80000003, eax = 67694520 ebx = 432d7468 ecx = 2065726f edx = 636f7250 + eax in: 0x80000004, eax = 6f737365 ebx = 20202072 ecx = 20202020 edx = 00202020 +-eax in: 0x80000005, eax = ff40ff40 ebx = ff40ff40 ecx = 20080140 edx = 40040140 +-eax in: 0x80000006, eax = 26006400 ebx = 66006400 ecx = 02006140 edx = 00808140 +-eax in: 0x80000007, eax = 00000000 ebx = 0000001b ecx = 00000000 edx = 00006599 +-eax in: 0x80000008, eax = 00003030 ebx = 00000007 ecx = 0000400f edx = 00000000 ++eax in: 0x80000005, eax = 01ff01ff ebx = 01ff01ff ecx = 40020140 edx = 40020140 ++eax in: 0x80000006, eax = 00000000 ebx = 42004200 ecx = 02008140 edx = 00808140 ++eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x80000008, eax = 00003028 ebx = 00000000 ecx = 00000007 edx = 00000000 + eax in: 0x80000009, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000000a, eax = 00000001 ebx = 00008000 ecx = 00000000 edx = 0001bcff ++eax in: 0x8000000a, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x8000000b, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x8000000c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x8000000d, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +@@ -38,10 +38,5 @@ + eax in: 0x80000016, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x80000017, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + eax in: 0x80000018, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x80000019, eax = f040f040 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001a, eax = 00000003 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001b, eax = 000003ff ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001d, eax = 00004121 ebx = 01c0003f ecx = 0000003f edx = 00000000 +-eax in: 0x8000001e, eax = 00000000 ebx = 00000100 ecx = 00000000 edx = 00000000 +-eax in: 0x8000001f, eax = 00000007 ebx = 0000016f ecx = 0000000f edx = 00000000 ++eax in: 0x80000019, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 ++eax in: 0x8000001a, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 + + +The core topology info used by Linux (see linux/arch/x86/kernel/cpu/amd.c:amd_get_topology()) is actually at CPUID[0x8000001e]. + +AMD's documentation is a bit confusing, as the Architecture Programmer's Manual still refers to CPUID[0x8000001e].EBX[bits 7:0] as "compute unit ID", but the Processor Programming Reference for AMD Family 17h documents the same bits as "Core ID". We can implement CPUID[0x8000001e] and print the existing warning only if CPU vendor is AMD and cpuid_family != 0x17. + +Posted few patches to support this feature on AMD EPYC processors. Feel free to test and review. +1. Kernel kvm patch + https://patchwork.kernel.org/patch/10190107/ +2. qemu patches + https://patchwork.kernel.org/project/qemu-devel/list/?submitter=178527 +Thanks + +just to be clear.. The kernel kvm patch is rebased on linux-next. If you are on older kernel then try this kernel patch. https://patchwork.kernel.org/patch/10031775/ plus qemu patch. + + +I tried the above patches on a TR 1900X and they do not help to enable SMT. I still receive the warning. + +Also, with the patches applied, the CPU now identifies as EPYC in the guest. + +Error I see in terminal: +AMD CPU doesn't support hyperthreading. Please configure -smp options properly. + +Error I see in my windows 10 vm: +SYSTEM THREAD EXCEPTION NOT HANDLED + +I am unable to use Qemu at all. Serious problem. + +CPU: AMD Ryzen 5 1600X Six-Core Processor × 6 + +QEMU 3.0 has limited TOPOEXT support. You can try using `-cpu EPYC`, and the `threads` option is supposed to work. + +I got it to work: +sudo nano /etc/modprobe.d/kvm.conf +add "options kvm ignore_msrs=1" (without quotes) +reboot + +Then changing "-machine q35" to "-machine pc" kept it from crashing randomly. + +@ryzen27: do you have dmesg logs showing the MSRs being written by the guest? You may be hitting the bug described at https://bugzilla.redhat.com/show_bug.cgi?id=1592276 + +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.] + +Found the same problem using Gnome boxes, as I understand it uses QEMU. + +Error I see in gnome boxes when I'm trying to install windows 10 vm: +SYSTEM THREAD EXCEPTION NOT HANDLED + +Fresh install of Ubuntu 22.04 +CPU: AMD Ryzen 7 1700 + +The solution posted by asd fghjkl (ryzen27) worked for me too: + +sudo nano /etc/modprobe.d/kvm.conf +add "options kvm ignore_msrs=1" (without quotes) +reboot + + +I was able to avoid rebooting after following @Andrii's instructions - https://bugs.launchpad.net/qemu/+bug/1703506/comments/19 - above: + +systemctl stop libvirtd libvirtd-admin.socket libvirtd-ro.socket libvirtd.socket +sudo modprobe -r kvm_intel kvm +systemctl start libvirtd libvirtd-admin.socket libvirtd-ro.socket libvirtd.socket + +These instructions to avoid rebooting might not work for those using a non-Intel CPU as you'll have a different kernel module. You can check by running `lsmod | grep kvm`. + +Cheers, +ak. + +System info: +# inxi -CMz +Machine: + Type: Laptop System: Dell product: Precision M6700 v: 01 serial: <filter> + Mobo: Dell model: 0JWMFY v: A00 serial: <filter> UEFI: Dell v: A20 date: 11/30/2018 +CPU: + Info: quad core model: Intel Core i7-3840QM bits: 64 type: MT MCP cache: L2: 1024 KiB + Speed (MHz): avg: 3607 min/max: 1200/3800 cores: 1: 3588 2: 3615 3: 3638 4: 3588 5: 3588 + 6: 3638 7: 3617 8: 3588 + + +This affected me. Took me several days. + + +The solution posted by asd fghjkl (ryzen27) worked for me as well: + +sudo nano /etc/modprobe.d/kvm.conf +options kvm ignore_msrs=1 +and then rebooted + +I'm very glad i found this thread. Don't know where to report this or if it's even a bug, But hope it gets fixed! + diff --git a/results/classifier/118/all/1703795 b/results/classifier/118/all/1703795 new file mode 100644 index 00000000..3f56cb59 --- /dev/null +++ b/results/classifier/118/all/1703795 @@ -0,0 +1,96 @@ +graphic: 0.978 +register: 0.972 +user-level: 0.955 +peripherals: 0.949 +device: 0.946 +socket: 0.945 +architecture: 0.943 +debug: 0.943 +virtual: 0.942 +assembly: 0.940 +kernel: 0.939 +semantic: 0.937 +performance: 0.929 +files: 0.927 +boot: 0.927 +arm: 0.921 +vnc: 0.917 +hypervisor: 0.911 +risc-v: 0.911 +network: 0.905 +PID: 0.903 +TCG: 0.901 +permissions: 0.900 +mistranslation: 0.894 +KVM: 0.887 +ppc: 0.878 +VMM: 0.871 +x86: 0.833 +i386: 0.798 + +Unable to release mouse in SDL2 mode + +Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. + +This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. + +Which version of SDL2 are you using? Could you please try to reproduce it with the latest version to see whether the problem has been fixed there? + +I'm using SDL2-2.0.5, which I believe is the latest already. + +I am seeing this on my system as well - the exact same symptoms. Has anyone investigated this problem? + +I'm also seeing this problem with -vga vmware in case that matters. + +Additionally 2ec78706d188df7d3dab43d07b19b05ef7800a44 also broke keyboard with SDL1 so that e.g. in a Windows password prompt backspace and enter just inserts chars instead of doing actions so now the workaround to avoid this bug (--with-sdlabi=1.2) is also unusable. + +Can you file a separate bug for the SDL1 backspace problem - it was not intended to cause problems like that. + +On Thu, 1 Feb 2018, Daniel Berrange wrote: +> Can you file a separate bug for the SDL1 backspace problem - it was not +> intended to cause problems like that. + +Unless you want it tracked in a bug I'm happy with a fix submitted to the +list eventually without being separately tracked on launchpad. I would've +reported this on the mailing list normally but since this is also relevant +here due to SDL2 also not uasable beacause of this bug I've commented +here so people affected by this know about both problems. + + +workaround: don't click into the guest window before the tablet driver loads. + +When qemu mouse mode changes from relative to absolute +we must turn off sdl relative mouse mode too. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1703795 +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + ui/sdl2.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/ui/sdl2.c b/ui/sdl2.c +index 812c315891..858e04d7c0 100644 +--- a/ui/sdl2.c ++++ b/ui/sdl2.c +@@ -249,6 +249,7 @@ static void sdl_mouse_mode_change(Notifier *notify, void *data) + if (qemu_input_is_absolute()) { + if (!absolute_enabled) { + absolute_enabled = 1; ++ SDL_SetRelativeMouseMode(SDL_FALSE); + absolute_mouse_grab(&sdl2_console[0]); + } + } else if (absolute_enabled) { +-- +2.9.3 + + + +I can confirm that the patch from comment #9 appears to fix the original problem. + +The patch works for me too. Thanks. + + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8dfa3061ce56d871dc9df + |