Even Rouault wrote:
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 ?
The PCI device is not necessarily an advantage is terms of performance
and it will be more complicated to implement on both the host and the
guest. But it is better in terms of security and it avoids adding
unnecessary hacks in the CPU core (for example, I consider the use of
virtual addresses as a hack).
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 ?
Yes.
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.
You have no choice but adding a kernel module to handle the transfers to
and from the PCI device. Basically you must write a small XFree DRM like
kernel driver. Since the PCI device will only handle physical memory,
the kernel driver will convert the virtual addresses to physical
addresses and ensure that the corresponding pages are not swapped out by
the guest OS. The PCI device must handle lists of physical I/O regions
so that no memcpy will be needed to do the transfers (scatter/gather
DMA). The performance should be the same as your current implementation.
Moreover, your protocol could handle queueing of several OpenGL commands
in a FIFO because "int 0x99" or the equivalent PCI write command takes
some time to execute, especially when using kqemu where an exception is
raised.
Another point is that I fear that your current use of glX is not
portable and can lead to subtle problems. You should rely on SDL/OpenGL
on the host side and leave glX on the guest OS.
All in all, what I propose gets very close to adding something like a
real 3d VGA device in QEMU and a new 3d driver in X11 !
[My intend before your submission was to emulate a recent Intel 3d card
because their protocols are mostly documented now (at least in the X11
source !) and because these recent cards support higher level 3d
operations such as hardware 3d transformations. My guess is that
converting their DMA commands to OpenGL is easy.
As writing an Intel 3d emulation would take time and is likely to be
very complicated to tune for closed source guest OSes, I think it is
safer to begin by improving your proposal.]
Regards,
Fabrice.
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
