https://bugzilla.kernel.org/show_bug.cgi?id=202091 Bug ID: 202091 Summary: Running a specific DOS program in qemu causes 10 WARNINGs/second and choppy mouse movement Product: Virtualization Version: unspecified Kernel Version: 4.20.0-arch1-1-ARCH Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: kvm Assignee: virtualization_kvm@xxxxxxxxxxxxxxxxxxxx Reporter: asmqb7@xxxxxxxxx Regression: No Created attachment 280183 --> https://bugzilla.kernel.org/attachment.cgi?id=280183&action=edit 5MB, 58k line, dmesg output Hi This is a low-priority just-in-case report. It may prove useful (ie solve others' problems); on the other hand it may suddenly disappear on my machine next kernel update. Given that a DOS program seems to be the cause I suspect an edge case is triggering this but I'm reporting this anyway because it causes kernel-level user unfriendliness (slow mouse, unusable system) and whatever guest instructions are causing this might be easy to synthesize. While going through some random-looking files in my home directory, I wanted to recall out what a particular ISO did, so I fired it up in qemu. The ISO in question is this one (auto-download link): https://sourceforge.net/projects/vmtce/files/vmtce.bin.1.21.iso.zip/download Very unexpectedly, my mouse (on the host, inside or out of the qemu window) promptly became like a very slow slideshow (one jump every... 650ms or so) and examining dmesg showed tens of thousands of lines of WARNINGs like this one: --- Dec 30 01:17:09 t400 kernel: WARNING: CPU: 0 PID: 1496 at arch/x86/kvm/mmu.c:2066 nonpaging_update_pte+0x5/0x10 [kvm] Dec 30 01:17:10 t400 kernel: Modules linked in: msr lz4 lz4_compress ccm 8021q garp mrp stp llc i915 uvcvideo kvmgt ath9k_htc vfio_mdev joydev arc4 ath9k_common mdev mousedev videobuf2_vmalloc ath9k_hw iwldv> Dec 30 01:17:10 t400 kernel: mbcache jbd2 fscrypto sr_mod cdrom sd_mod uhci_hcd ahci ata_generic pata_acpi libahci serio_raw atkbd libata libps2 ehci_pci firewire_ohci scsi_mod firewire_core crc_itu_t ehci_> Dec 30 01:17:10 t400 kernel: CPU: 0 PID: 1496 Comm: qemu-system-i38 Not tainted 4.20.0-arch1-1-ARCH #1 Dec 30 01:17:10 t400 kernel: Hardware name: LENOVO 6474RS2/6474RS2, BIOS 7UET91WW (3.21 ) 12/06/2010 Dec 30 01:17:10 t400 kernel: RIP: 0010:nonpaging_update_pte+0x5/0x10 [kvm] Dec 30 01:17:10 t400 kernel: Code: 00 00 00 00 00 66 66 66 66 90 31 c0 c3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 <0f> 0b c3 0f 1f 84 00 00 00 00 00 66 66 66 66> Dec 30 01:17:10 t400 kernel: RSP: 0018:ffffbee3821a7a50 EFLAGS: 00010202 Dec 30 01:17:10 t400 kernel: RAX: ffffffffc0d9bb10 RBX: 0000000000000701 RCX: ffffbee3821a7a80 Dec 30 01:17:10 t400 kernel: RDX: ffffa1b49210e010 RSI: ffffa1b4921b1460 RDI: ffffa1b492280000 Dec 30 01:17:10 t400 kernel: RBP: ffffa1b4921b1460 R08: ffffa1b49210e010 R09: 0000000000000008 Dec 30 01:17:10 t400 kernel: R10: 0000000000000004 R11: 0000000000000003 R12: 0000000000000000 Dec 30 01:17:10 t400 kernel: R13: ffffa1b49210e010 R14: ffffa1b492280000 R15: ffffbee3821a7a88 Dec 30 01:17:10 t400 kernel: FS: 00007fbbc0d34700(0000) GS:ffffa1b4b7a00000(0000) knlGS:0000000000000000 Dec 30 01:17:10 t400 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 30 01:17:10 t400 kernel: CR2: 0000000000000000 CR3: 000000011f58a000 CR4: 00000000000426f0 Dec 30 01:17:10 t400 kernel: Call Trace: Dec 30 01:17:10 t400 kernel: kvm_mmu_pte_write+0x487/0x4a0 [kvm] Dec 30 01:17:10 t400 kernel: kvm_page_track_write+0x7c/0xa0 [kvm] Dec 30 01:17:10 t400 kernel: emulator_write_phys+0x36/0x50 [kvm] Dec 30 01:17:10 t400 kernel: emulator_read_write_onepage+0xef/0x330 [kvm] Dec 30 01:17:10 t400 kernel: emulator_read_write+0xc8/0x180 [kvm] Dec 30 01:17:10 t400 kernel: segmented_write+0x5d/0x80 [kvm] Dec 30 01:17:10 t400 kernel: writeback+0x125/0x260 [kvm] Dec 30 01:17:10 t400 kernel: x86_emulate_insn+0x7b4/0x10a0 [kvm] Dec 30 01:17:10 t400 kernel: x86_emulate_instruction+0x33e/0x720 [kvm] Dec 30 01:17:10 t400 kernel: vmx_handle_exit+0x3f6/0x750 [kvm_intel] Dec 30 01:17:10 t400 kernel: kvm_arch_vcpu_ioctl_run+0xbfd/0x1b30 [kvm] Dec 30 01:17:10 t400 kernel: ? kvm_vm_ioctl_irq_line+0x23/0x30 [kvm] Dec 30 01:17:10 t400 kernel: kvm_vcpu_ioctl+0x2b8/0x600 [kvm] Dec 30 01:17:10 t400 kernel: ? do_futex+0x2a8/0xa90 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x40/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x34/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x40/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x34/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x40/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x34/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x40/0x70 Dec 30 01:17:10 t400 kernel: ? __switch_to_asm+0x34/0x70 Dec 30 01:17:10 t400 kernel: do_vfs_ioctl+0xa4/0x630 Dec 30 01:17:10 t400 kernel: ksys_ioctl+0x60/0x90 Dec 30 01:17:10 t400 kernel: __x64_sys_ioctl+0x16/0x20 Dec 30 01:17:10 t400 kernel: do_syscall_64+0x5b/0x170 Dec 30 01:17:10 t400 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Dec 30 01:17:10 t400 kernel: RIP: 0033:0x7fbbc4d2380b Dec 30 01:17:10 t400 kernel: Code: 0f 1e fa 48 8b 05 55 b6 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 25 b6 0c> Dec 30 01:17:10 t400 kernel: RSP: 002b:00007fbbc0d31ec8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Dec 30 01:17:10 t400 kernel: RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbbc4d2380b Dec 30 01:17:10 t400 kernel: RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000c Dec 30 01:17:10 t400 kernel: RBP: 0000000000000000 R08: 0000560c3983f170 R09: 0000000000000001 Dec 30 01:17:10 t400 kernel: R10: 0000000000000001 R11: 0000000000000246 R12: 00007fbbc29e41c0 Dec 30 01:17:10 t400 kernel: R13: 00007fbbc6ae2000 R14: 0000000000000000 R15: 00007fbbc29e41c0 Dec 30 01:17:10 t400 kernel: ---[ end trace 52c2ee83f3f969c6 ]--- --- The remainder of the WARNINGs are virtually identical; always the same file, line and function. I have attached the entire `journalctl -b 0` of the session in question. (Including the whole thing lets me conveniently sidestep any possibly-incorrect assumptions I might make about what parts to leave out.) For reference, I was using: qemu-system-i386 -enable-kvm -cdrom /nfs/home/i336/vmtce/vmtce.iso -sdl Some context: - I'm running the stock Arch kernel, 4.20. Everything was updated yesterday. - To save you decoding the model from DMI: This is a ThinkPad T400 (Core2 P8600). - The mouse (well, mice - touchpad and trackpoint) use(s) PS/2, and the extreme skittering makes me think I'm getting severe quantities of dropped interrupts. I have this laptop's built-in (mini-PCIe) Wi-Fi disabled because it likes crashing too much and one specific point in the crash process causes the mouse to sloooooow dooooown for about half a second (while the Wi-Fi module restarts, I think). The choppiness is about 2-3x worse with the issue I'm describing here, though. - I've had Windows 7 running in qemu the whole time I type this, and this has only resulted in a few "perf: interrupt took too long"s (unsurprising for a decade-old chip) and a note about my TSC instability; nothing else. I consider booting Win7 a reasonable acid test (along with a quick fire-up of Tiny Core Linux, also fine); by all means suggest other ideas, although I have limited diskspace. - This would sometimes reproduce instantly, but sometimes I'd need to throw the mouse around the screen a bit, focus different windows, etc, to make things suddenly slow down all at once. Grabbing the qemu window did it at one point. - This machine has an as yet un-tracked-down weird issue with coming out of sleep sometimes - everything resumes okay, but it's like the CPU is in some kind of slow motion. Doesn't quite cause an unusable mouse, but does result in a system I have to hard power off because it's too slow to properly reboot. It sounds like I'm describing "hi, this weird edge case broke on my half-dead machine" :) but I'm just trying to accurately report everything I can think of (including the things I'm personally filing under "it's probably not that") so a direct path to the correct root cause can be found quickly. By all means request tests, additional info, etc, and hopefully this keeps reproducing. Cheers -- You are receiving this mail because: You are watching the assignee of the bug.
