qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Robert Wittams <robert@wittams.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Impractical ideas?
Date: Thu, 06 May 2004 17:08:53 +0100	[thread overview]
Message-ID: <c7dnul$vto$1@sea.gmane.org> (raw)

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

             reply	other threads:[~2004-05-06 16:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-06 16:08 Robert Wittams [this message]
2004-05-06 18:06 ` [Qemu-devel] Impractical ideas? John R. Hogerhuis
2004-05-06 21:52   ` J. Mayer
2004-05-06 22:11     ` John R. Hogerhuis
2004-05-07  1:34       ` Jason Gress
2004-05-07  1:38         ` John R. Hogerhuis
2004-05-07  9:44 ` David Woodhouse
2004-05-07 17:13   ` Irvin Probst
2004-05-07 17:51     ` Chad Page
2004-05-07 19:21       ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='c7dnul$vto$1@sea.gmane.org' \
    --to=robert@wittams.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).