From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BDr9O-0007it-TM for qemu-devel@nongnu.org; Wed, 14 Apr 2004 16:38:26 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BDr8r-0007Yt-C6 for qemu-devel@nongnu.org; Wed, 14 Apr 2004 16:38:24 -0400 Received: from [81.228.9.105] (helo=av1-1-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BDr8r-0007YZ-0m for qemu-devel@nongnu.org; Wed, 14 Apr 2004 16:37:53 -0400 Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 52AB637E59 for ; Wed, 14 Apr 2004 22:37:52 +0200 (CEST) Received: from putte2k (h151n2fls306o994.telia.com [81.225.243.151]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 2FD2138011 for ; Wed, 14 Apr 2004 22:37:52 +0200 (CEST) Message-ID: <002801c42260$67c56110$0401a8c0@putte2k> From: "Mike Nordell" Subject: Re: [Qemu-devel] Win2k mouse Date: Wed, 14 Apr 2004 22:36:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hetz Ben Hamo wrote: > Mike Nordell has send a keyboard/mouse fix for win2k as a guest, > but I only see keyboard fix in the CVS. Actually, the fix wasn't specifically for win2k guest. It was a deadlock that would most probably have occured in any guest OS having both mouse and keyboard input. The problem was that (PS/2) mouse input was given priority when QEMU came to choose between mouse and keyboard interrupts to report to the CPU, but when the guest was reading I/O port 0x60 the keyboard queue had priority. Imagine the deadlock when both mouse and keyboard messages were pending. :-) The easiest way to see this bug in action was by grabbing the mouse and then alt-tab (or whatever the kbd shortcut for switching to another window is in your environment) to another window. Voila. Instant guest input lock. I've got a feeling, though not yet any strong evidence, that since QEMU PC emulation is yet so incomplete (it's basically like a 386 PC, with a 686 CPU) NT switches to some safety-mode for a lot of stuff. This could potentially involve a lot of switching between protected mode and v86 mode, which would slow down the emulation as seen. It's btw not only mouse - try starting the Task Manager in the guest and watch the CPU pegged while running it. Close that one and start PerfMon. Add e.g. interrupts/s or DPC time or... anything. The numbers are off the chart (probably NT can't even get them, but it might also be they are so insanely high they can't be trusted), but it's no longer pegging the CPU (you'll notice it's no longer using all available host CPU). I'm right now on my way to add some profiling code to QEMU to see what's going on in this area. While NT as guest behaves like this, just booting it is a test of patience why it might take some days before I get any real numbers. /Mike