Re: [Qemu-devel] Impractical ideas?

[John R. Hogerhuis]

You are suggesting some kind of pass-through driver.

Some of the things you would have to configure for each instance of such
a driver would be:

The set of IO ports
The set of Interrupts to pass through
DMA stuff (knowledge deficit here), any kind of shared memory

So to even start you would have to track down this information from the
driver. I don't know much about windows drivers, but I suspect you could
gather some of this information from the driver itself, or resources it
registers when it is installed.

Of course there's no way you could share the device with the host OS
while running.

To me this sounds like more a job for Bochs, but I suppose the concept
is universally applicable.

That said I think it would be really hard. But if such a theoretical
device existed it would help you crack protocols better than just trying
to disassemble a driver, since you would get to see the back-and-forth
of the system in action. The equivalent of a network sniffer for APIs.

The "rootless window" issue has come up before, you can check the
archives. All that is left is design, implementation and testing ;-)...

-- John.

On Thu, 2004-05-06 at 09:08, Robert Wittams wrote:
> 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
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
>