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 1BLmBn-0005gM-Bq for qemu-devel@nongnu.org; Thu, 06 May 2004 12:57:39 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BLlwZ-0001fC-CU for qemu-devel@nongnu.org; Thu, 06 May 2004 12:42:26 -0400 Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BLllz-0006vG-SA for qemu-devel@nongnu.org; Thu, 06 May 2004 12:30:59 -0400 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BLllz-0000mN-00 for ; Thu, 06 May 2004 18:30:59 +0200 Received: from demon-gw.antistream.com ([62.49.248.97]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 May 2004 18:30:59 +0200 Received: from robert by demon-gw.antistream.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 May 2004 18:30:59 +0200 From: Robert Wittams Date: Thu, 06 May 2004 17:08:53 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Sender: news Subject: [Qemu-devel] Impractical ideas? 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 Hi, Having installed Win2k and various Linuxes under qemu, I've got all excited at the potential of this project, and have been entertaining all kinds of possibly impractical ideas... I was wondering if anyone had thought of using Qemu + a special kernel module to do reverse engineering of binary or windows only drivers. I'm not sure if I'm missing something really obvious, but it seems like the following should be possible: Run a virtual machine in qemu with, for example, the binary nvidia drivers on a linux system. On the host, a kernel module is configured that can perform any operations on the hardware that are necessary (io writes and dma, etc) and report interrupts to qemu. Run a series of OpenGL operations on the guest os, which will cause the driver to do its hardware operations in qemu. These get passed on by qemu to the kernel driver, which then performs them on the real hardware. This way, you would end up with knowledge of what the driver sends to the card for any particular set of ( opengl state, card state, operation, arguments.) It should even be possible to automatically create a (ridiculous) opengl implementation that would work for the same exact set of operations in the same order as the test run... and fail for anything else ;-) How useful the information gleaned would be isn't clear to me (given eg how hard it is to even understand the obfuscated free nvidia driver), and a GPU is probably the most complex example to try to do this for due to the sophistication of the drivers eg shader/ vertex program compilers etc. Maybe a network card driver would be more realistic. Another possibly hairy idea - A windows graphics driver that mirrors window contents into separate X Windows ( or some windowing abstraction), allowing a "rootless" integration of Win32 programs that don't run / run badly in wine.. but I expect if this was at all easy, vmware would have done it by now. Maybe this could be done in guest userspace, by just sending the screen coordinates of all the windows to qemu, copying the screen area of these to separate X windows, and just update them when possible. . Rob