Le Jeudi 16 Novembre 2006 23:41, vous avez écrit : > My main remark is that the host/guest communication system must be > changed and I can help you to implement it. I would prefer to use a PCI > device and to avoid any i386 dependent code. For the PCI device, using > the Bochs VGA adapter could be a possible idea. All the parameters and > data should be transmitted as if the PCI device was doing DMA. A single > I/O port could be used to start executing a list of OpenGL commands.
Hi, I would indeed appreciate help, or at least some pointers to start in the direction you propose, as I know hardly anything about hardware programming, such as PCI, memory mapped region, DMA, etc... So my questions may sound very naive. As you stated, the current solution is i386 dependent, but this dependancy is very thin, so I imagined that it should possible to find equivalent of the current int 0x99 trap for other architectures. Apart from portability to other architectures, what would be the other advantages of a solution based on a PCI device ? Better security ? Better performance when KQEMU is enabled ? I've looked at vga.c and I've the feeling that with cpu_register_io_memory/cpu_register_physical_memory you can install callback functions that will intercept reads/writes to a range of the physical memory of the target machine. Am I right ? But I don't see how the replacement libGL can read/write physical memory from a userland process. I suppose it needs some special priviledges to use for example a ioctl, or maybe writing a kernel module. So it would become guest OS dependant. Furthermore, doesn't this solution imply more memcpy that may affect performance ? Currently, if a memory range of a guest process (let's say a texture) is by chance mapped contiguously into guest physical memory, we don't need to do any copy before passing it to the host libGL, though I've not benchmarked if it really improves performance. Regards, Even _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
