qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Impractical ideas?


From: J. Mayer
Subject: Re: [Qemu-devel] Impractical ideas?
Date: Thu, 06 May 2004 23:52:58 +0200

On Thu, 2004-05-06 at 20:06, John R. Hogerhuis wrote:
> 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.
> 

You just need to know the IRQ, IMHO:
you just have to check all accesses and print all IO, memory and DMA
requests that aren't handled by any devices. And for most devices, you
can parse the PCI descriptors and get the needed informations. 

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

You cannot share the device, but you may use it if the host OS doesn't.

> 
> 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.

Sounds right. But it may be possible to make a "false" driver that just
send the paquets that were sniffed from a guest OS. You'll never get a
real full working driver this way, but you may be able to control some
of the device resources...

> 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
> > 
> > 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-- 
J. Mayer <address@hidden>
Never organized





reply via email to

[Prev in Thread] Current Thread [Next in Thread]